openvsp: init at 3.40.1

[Kek5chen]

The openvsp software package for nixpkgs.

Resolves #349534

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[Kek5chen]

uhm.. i'm pretty sure my package is properly formatted.. not according to nixfmt but comparing it to other packages... is nixfmt really the defacto or is it fine the way it is?

Also some thoughts about my custom phases:

OpenVSP comes packaged for Ubuntu and RPM based and on normal linux file structures it puts all its packages into /opt. I just extract the ones that I want. It's also a bit finicky because of it's urgent needs to package dynamic libraries. Any suggestions are appreciated.

Edit: Ah, finally figured it out while packaging another package. using nixfmt is not sufficient. using nixfmt-rfc-style is the way.. that's a bit weird, but alright.

[Kek5chen]

openvsp is really a weird and annoying build that's just super demanding... it falls apart if you even as to look at it wrong

[luzpaz]

Heads up, upstream just released 3.41.0
https://openvsp.org/blogs/announcements/2024/11/10/openvsp-3-41-0-released

[Kek5chen]

Heads up, upstream just released 3.41.0

https://openvsp.org/blogs/announcements/2024/11/10/openvsp-3-41-0-released

Thanks for the info.. I'll adjust this PR then.

[luzpaz]

openvsp is really a weird and annoying build that's just super demanding... it falls apart if you even as to look at it wrong

@Kek5chen any chance you could provide some feedback to the upstream packagers about this ?

[Kek5chen]

I mean, the issue is mostly with their messy dependency management. But maybe someone could persuade them to clean it up a bit. I don't have the time to do that right now though.

[luzpaz]

@Kek5chen could you provide some short tips for them here?

[Kek5chen]

@luzpaz for that I'd have to analyse the situation a bit more precisely. It just deviates from the standard way by a far margin, thus building it is really not as straightforward as just using automake to derive which build type it is. Just knowing it's cmake and providing flags will fail as it doesn't know that it has to build the libraries first or the openvsp build will fail. All I can say right now is that I've never seen a software ship its dependencies as zip files and then require the user to build them. Feels like a bunch of windows devs to me.

[Kek5chen]

hmm. should i squash this or leave it as init + update? I think this is cleaner.

[ramcdona]

If you want a one-stop build for OpenVSP, that exists.

Just point CMake at the SuperProject. It will build the required libraries and then build the main VSP project -- all as one step.

You can tell the SuperProject to use any of the system installed libraries that your Linux Distribution bundles. Anything not provided by the distribution will be built statically and linked in.

I'll admit that the SuperProject doesn't get a lot of use, so if something there is out of date, let me know -- it is a bug. Ideally, any of the OpenVSP CMake-type build options should be able to be passed to the SuperProject and down to the Libraries and VSP sub-projects.

While not super common, this is not a pattern that I cam up with -- it is usually called the 'SuperBuild' pattern in the CMake world.

Every one of the bundled libraries can be bypassed for a system-installed version with a command line parameter passed to CMake. For example...

-DVSP_USE_SYSTEM_FLTK=True

If you want to bypass 100% of the libraries, then you can just go directly to the VSP project. However, that is impractical because we have a bunch of esoteric dependencies that you aren't going to have on the system.

I bundle the dependencies as *.zip files for two reasons...

1. Most importantly, I have users who need to build OpenVSP on air-gapped machines where they do not have the ability to ask a sys-admin to install a bunch of packages. A build system that connects over the internet to obtain dependencies won't work.

2. Using the zip files (with the upstream project git SHA in the name) allows me to rigorously identify exactly the version of the library that was used to build a particular release. Likewise, anyone building that version knows they are using the exact same version of the dependency as I am.

OpenVSP ends up using modified or between-release versions of many of its dependencies. Usually these are just build fixes, but often enough they are more than that. In general, these upstream projects move very slowly about accepting changes and making 'official' releases including what is needed.

A bunch of OpenVSP's dependencies are pretty esoteric. There is no reasonable expectation that they will become packages in most Linux distributions. Most projects would strip apart their build system and just dump the files into their source tree. Using the ExternalProject_Add pattern allows us to mostly keep these projects at an arms length and use the upstream build system. It also makes it much easier to update to new versions when the upstream project updates.

I 100% do not expect my users to deal with any of this. I expect my users to download VSP from the website and run it there. My users are aircraft designers. Most of them have never used a compiled language in their lives -- if they have, it was Fortran 30 years ago in college.

One challenge with Linux builds (why OpenVSP's install target is unsatisfying) is that the Linux paradigm doesn't really it OpenVSP very well. I would love some help here. OpenVSP is not only distributed with a handful of executables, but also a whole bunch of example files and other similar stuff. Where is the Unixy place to put stuff like that? It needs to be easy to navigate to (easy to find) by the user.

Many of my Linux users don't want OpenVSP installed on their system -- they prefer working with a local version in their home directory. This gives them the ability to update frequently without involving the sys-admin. It also makes it easy for them to keep multiple versions around in an unsophisticated way.

I'm more than happy to take feedback, but you have to realize that I'm pretty much a one-man show. I work nearly full time on OpenVSP as a freelancer -- but that also means that development priorities are set by the paying customers.

I have zero time to learn the packaging requirements of a bunch of random Linux distributions. Help and patches are of course accepted.

[ramcdona]

BTW, I had to release 3.41.1 just after 3.41.0 as I missed a small handful of last minute changes.

No changes to compiled files, everything is in some of the supporting Python for people using the Python API.

If you're tracking the latest, you'll want to jump to that.

[Kek5chen]

@ramcdona there you have it. A good reason to package stuff badly. I honestly get you, and I never said anything about changing your ways because well, yeah, I did already believe that there were good reasons for you to do the things you do. The info with the super build though is helpful and I'm probably going to be able to use that to get this build a little more clean. Though the manual sorting through binaries will most likely keep being an issue because you decide to put all your software into /opt. Otherwise i could just package a deb and be done with it. Well- thanks for your work though.

[ramcdona]

I really don't think that OpenVSP is packaged badly. Unconventionally perhaps, but badly no. The traditional Unix way would have been to do nothing about the dependencies -- leave the person compiling to track them all down, compile them all, install them all, and get them all working.

If that is what you prefer, feel free to ignore the Libraries subproject and start your build process from the VSP subproject. If you can even find all the dependencies and figure out how to get them to build, pray that they're the right versions, because all the projects are independent, we have no idea when incompatibilities are introduced as they move forward.

I don't do my development work on Windows and I'm not a fan of the platform, but about 90% of my users are on Windows with most of the remainder on Mac. A true cross platform build system is a must.

Autoconf is a house of cards -- while prevalent in a very Unixy way, it is amazing that it ever works at all.

I would recommend you stick with the separate Lib and VSP build for now -- at least until you prove out that whatever options you want to use get passed through everywhere.

Are you a VSP user, or someone coming from the distribution side just wanting to help package this? If the former, it should be pretty easy to modify OpenVSP to pass any of the build variables that are missing around. If the latter, then I recommend you ask a VSP user (@luzpaz) to take care of this as it is a lot to ask of a distribution side packager.

The CMake build system will build a *.deb, *.rpm, or *.zip file. If you're going to strip stuff out of it, I would suggest you just use the *.zip file, it'll make your life that much easier.

Installing to /opt is the CMake default -- I have made no decisions about it. I'd be willing to be that passing

-DCMAKE_INSTALL_PREFIX=/desired/install/path

Would have the desired effect.

Where do you want the files installed? What is your preference?

OpenVSP includes:

Several executable binaries (vsp, vspscript, vspaero, vspviewer, vsploads - the rest probably don't matter). These files should be co-located so OpenVSP can find the others.

Online help files (*.html, *.css, *.png) in the help and help/images directories. If these get moved to someplace else, VSP will need to be modified to find them. This is OK, but it needs to be a predictable location.

A Python package that includes lots of *.py files, but also three executables (vspaero, vspviewer, vsploads) and two binary shared libraries (vsp.so and vsp_g.so).

A collection of example user-defined components in the 'CustomScripts' directory. OpenVSP will search for this directory in 1) the user's home directory 2)the location where the vsp executable is stored 3) the working directory when VSP was launched.

A bunch of other example files of decreasing importance.

How would you like to see this installed on a Linux distribution?

[Kek5chen]

@ramcdona I appreciate your effort to explain and help us out very much, and I'm sure it's gonna be of help in packaging this, although I do not have the time currently to take care of t his.

It does build as of now, and that satisfies my requirements for this PR. If anyone else like @luzpaz is willing to improve this, then gladly PR to the fork and i'll check and merge it.

Otherwise, please review again.