Proposal to Add a Port for SuperNOVAS to vcpkg Registry

[AngelVeraHerrera]

Dear SuperNOVAS team,

My name is Ángel Vera Herrera, a computer engineer specialized in real-time systems at the Satellite Laser Ranging (SLR) station of the Royal Observatory of the Spanish Navy in San Fernando, Spain.

At our station, all software development is open source, and we actively use the NOVAS library within our C++ scientific library for SLR operations (LibDegorasSLR) that is used in all systems, such as the control system for our astronomical mount.

I’m very interested in testing and integrating the newer SuperNOVAS version, which looks like a fantastic evolution of the original package.

To that end, I would like to propose the idea of creating (or supporting the creation of) a vcpkg port for SuperNOVAS. Having the library available in the vcpkg ecosystem would significantly streamline its adoption in modern, complex development environments, especially those relying on reproducible and automated builds.

It's a pity that excellent scientific libraries like NOVAS (or SuperNOVAS now haha) are not yet available in vcpkg, while more general-purpose infrastructure libraries such as nlohmann-json are already widely integrated. Bringing SuperNOVAS into vcpkg would certainly help more developers and research institutions benefit from your work with minimal friction.

Thank you very much for your excellent contributions to scientific software. I’d be happy to help in any way I can to support this effort.

Warm regards,
Ángel Vera Herrera
SLR Station – Royal Institute and Observatory of the Spanish Navy
San Fernando, Spain

[attipaci]

Hi @AngelVeraHerrera,

That is certainly an excellent idea. Unfortunately I have absolutely zero experience with vcpkg, but if you would be interested to try integrate SuperNOVAS (without crippling its old-style UNIX make configuration), I'd very much welcome it, and will help you as much as I can along the way. Feel free to fork the repo, and prepare a pull request. If you have questions, you can ask them here, or in the PR, or as a separate discussion ticket. I'll do my best to help you getting it to work. Once both you and I are happy with the PR, it will be my privilege to include it in the next major release (probably around 1 November 2025)...

[attipaci]

P.S. If you think the vcpkg support would make more sense as a separate repo, which is dependent on SuperNOVAS (perhaps using SuperNOVAS as a submodule), that might be an option also. Again I have no idea what it takes for vcpkg, but I'm open to all good things... :-)

[AngelVeraHerrera]

Hi @attipaci !

Thank you very much for your kind reply, I truly appreciate your openness and willingness to support this integration effort.

Over the last few days, I’ve been discussing this idea with a good colleague and friend of mine, Manuel Perez (@manuoso), who is also a highly experienced senior C++ developer. He’s also interested in participating in the adaptation of SuperNOVAS to vcpkg.

Just as context, vcpkg is a popular cross-platform package manager for C/C++ libraries, backed by Microsoft and widely used in modern development environments. To enable vcpkg support, the key requirement is to provide an automatic CMake-based configuration that supports clean builds and packaging, while preserving existing build systems such as your traditional UNIX Makefile.

A few years ago, I actually created a fork of the original NOVAS library to migrate it to CMake (including support for both Windows and UNIX platforms) and even developed a lightweight C++ wrapper (namespaced as novas::), to make it more convenient to use in modern C++ codebases.

Our idea for moving forward would be to begin prototyping in a forked repository and follow a step-by-step plan focused initially on the core functionality (excluding Fortran and external libraries). Here's our proposed path:

1. Analyze the current Makefile, focusing on the basic C compilation flow (excluding Fortran/external libraries for now).
2. Create modern CMake support (for both Windows and Linux), including optional use of CMake presets.
3. Prepare CPack-based deployment options for standard packaging.
4. Study and prepare the modular integration into vcpkg, possibly subdividing functionality if necessary.
5. Mid term: Prepare a clean C++ wrapper (namespace could be snovas::) suitable for high-level integration in modern systems.
6. Do all the previous steps other time but adding Fortran/external libraries.

We’d of course aim to maintain your existing Make-based build system intact, so this CMake work would be an additive enhancement, not a replacement.

As for the BUILTIN_SOLSYS3 and BUILTIN_SOLSYS_EPHEM options — if they still define compile-time inclusion of solar system routines — this might be something to revisit. For broader compatibility with automated builds and packaging systems like vcpkg, it would be ideal to refactor these capabilities so that planetary calculators (e.g., earth_sun_calc(), planet_ephem_provider()) can be selected at runtime via set_planet_provider(), instead of being tied to compilation options. Otherwise, integrating and distributing multiple configurations could become quite complex.

However, we’re happy to begin with just solsys3, as it already covers many use cases, especially in embedded real-time systems like the ones I work with for sub-arcsecond telescope pointing.

We can certainly begin the development in a separate fork and evaluate later whether it would make sense to merge this effort into the main repository or maintain it as a complementary one.

Right now I’m a bit short on time — we’re working day and night on the pointing model for our SLR telescope system — but well, Manu and I will be able to find some space for this project :)

What do you think of this plan? Do you see any concerns, suggestions, or ideas that you’d like us to take into account?

Looking forward to hearing your thoughts.

PD: One of the problems we had with our telescope mount system with Novas was concurrency and parrallel calculations using OpenMP, but I've seen that you've solved it. That's great!

[attipaci]

Hi @AngelVeraHerrera,

That all sounds good to me. My only comments are:

As for the BUILTIN_SOLSYS3 and BUILTIN_SOLSYS_EPHEM options — if they still define compile-time inclusion of solar system routines — this might be something to revisit. For broader compatibility with automated builds and packaging systems like vcpkg, it would be ideal to refactor these capabilities so that planetary calculators (e.g., earth_sun_calc(), planet_ephem_provider()) can be selected at runtime via set_planet_provider(), instead of being tied to compilation options. Otherwise, integrating and distributing multiple configurations could become quite complex.

I think for the CMake configuration you just want to stick to BUILTIN_SOLSYS3=1 and DEFAULT_SOLSYS=3 precompiler macros, and include solsys3.c (as you suggest). You can forget about the legacy solsys1.c and solsys2.c (and the FORTRAN) completely. These are ancient modules, that don't even work with modern ephemeris data. If anyone still needs these, they can use the GNU Makefile instead to build a custom version of the library.

Also, I think for CMake you can forgo the static library support provided the GNU Makefile, and just focus on the shared (.so[.1]) libraries. (Again, those who need it, can use the GNU Makefile instead).

And, the CMake should also drop novascon.c / .h from the build. It's another ugly NOVAS legacy that needs to end up in the landfill.

However, I think the CMake should have the option to build CALCEPH support and perhaps also CSPICE support (perhaps automatically if these libraries are installed) for better out-of-the-box support for Solar-system objects. (Including these will require setting the appropriate USE_CALCEPH=1 or USE_CSPICE=1 precompiler macros, and build libsolsys-calceph.so[.1] or libsolsys-cspice.so[.1] targets).

The C++ wrapper is a great idea also. Perhaps you just want to wrap the more modern functions leaving some of the old NOVAS routines behind. Many of the new functions could be mapped as methods of the novas_frame, novas_time etc. classes (or equivalents in the C++ namespace). If we do that we should do it thoughtfully and carefully to make the C++ wrapper provide a nice clean interface.

I look forward to what you come up with for a starter,

cheers,

-- Attila.

[AngelVeraHerrera]

Hi @attipaci,

That all sounds perfect, thank you very much for the clarification! We didn’t realize that those were legacy components, so it's great to hear we can skip them, that certainly simplifies things!

It’s important to note that while we have strong experience in software engineering and RT systems, our astronomical background is more limited (my expertise is in SLR systems and I had to learn about precise star tracking specifically to implement the mount model of our telescope). So these kinds of clarifications from your side are extremely helpful and very much appreciated.

--

Regarding the static library support, we’re quite experienced in generating static builds across platforms, so we don’t anticipate any important issues there. Still, it's good to know that shared libraries are the preferred default for the project and we will focus on them.

--

As for CALCEPH and CSPICE support, that’s something we can study in a second iteration once we have the base running. Integrating them into CMake shouldn't be too complex, though automating their integration via vcpkg is more difficult.

--

About the C++ wrapper, we also believe it's an important component to help less experienced users interact with SuperNOVAS. We see this as a natural next step, once the port is complete. We were thinking of building this as an independent module (for example SuperNOVASxx).

Of course, you're in the best position to manage that development, given your deep understanding of the library internals, but we’d be happy to help and support wherever possible.

--

With the legacy elements now out of the way, my colleague and I will start by analyzing the current Makefile and revisiting the CMake adaptation I built some years ago for NOVAS. We'll do some initial tests and report back once we’ve got something concrete.

We'll be following this thread closely and are happy to receive any further comments or suggestions you may have along the way.

Cheers!

-- Ángel Vera

[attipaci]

Hi @AngelVeraHerrera,

I have some good news. @kiranshila has added CMake tooling to SuperNOVAS (in PR #222), so that will make your life a lot easier, once I merge it (probably early next week).

[kiranshila]

I'm glad I could help! I'm not sure how vcpkgs works exactly, but it seems having the cmake build helps a lot. For windows, mingw will be the only supported compiler as there is posix-specific stuff in supernovas. We could in theory create compatibility headers to swap out the posix stuff for windows-equivalents, but honestly mingw is fine, WSL is better, and just running Linux and freeing yourself from Micro$oft is best 😁.

Also if you like reproducible builds, you should check out Nix! It's a package manager on steroids that enables bit-for-bit reproducibility, all the way through the compiler to libc. With nix, you'll be able to generate binaries that are exactly the same until the end of time. We will be using this for our telescope project, and I plan to get supernovas on nixpkgs as soon as my cmake PR lands.

[manuoso]

Hi! First of all, we apologize for the limited time we have. We haven't stopped working on the issue! Angel and I have been reviewing your contribution, and I think it represents a great effort and dedication! We have been deliberating on the next steps and believe we could use your contribution alongside our initial idea of a modular system with CMake, providing a clear structure where the library itself, the algorithms within it, and the examples and installation are quickly identifiable. Also, since the main objective is to manage libraries in C/C++, we believe our approach remains to use vcpkg. We understand that it would make it easier for us to integrate the tool into multiple projects, along with automatic package downloads and the use of CMake presets. We have managed to freeze library versions based on the vcpkg version. In any case, vcpkg's cross-platform nature gives us the ability to use the libraries on Windows and Linux alongside the generated packages. We have infrastructure libraries that we link to our applications. The need to use MinGW isn't a problem since we have integrated development with Msys2, specifically using the UCRT environment. The project Ángel is working on requires native compilation on Windows because the SLR station mount control PLCs are from Bechoff and work with Windows 10 IoT. Best regards, Manuel. El dom, 31 ago 2025 a las 10:53, Kiran Shila ***@***.***>) escribió:

…

I'm glad I could help! I'm not sure how vcpkgs works exactly, but it seems having the cmake build helps a lot. For windows, mingw will be the only supported compiler as there is posix-specific stuff in supernovas. We *could* in theory create compatibility headers to swap out the posix stuff for windows-equivalents, but honestly mingw is fine, WSL is better, and just running Linux and freeing yourself from Micro$oft is best 😁. Also if you like reproducible builds, you should check out Nix! It's a package manager on steroids that enables bit-for-bit reproducibility, all the way through the compiler to libc. With nix, you'll be able to generate binaries that are exactly the same until the end of time. We will be using this for our telescope project, and I plan to get supernovas on nixpkgs as soon as my cmake PR lands. — Reply to this email directly, view it on GitHub <#196 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFRTUD3EJOAB3BOIZOWIVQT3QKZY5AVCNFSM6AAAAAB6P3SN32VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMRWGY3TCMA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[attipaci]

Another update: As of PR #255 (which has been merged to main), CMake builds with Microsoft Visual C are now also possible. This should help get vcpkg one step closer...

[attipaci]

I think I have created a vcpkg config. It works locally with 1.5.0-rc5. I will test it again with the next release candidate, which add proper MSVC build support. At that point I'll see if I can create a PR for the vcpkg repo for the supernovas port...

[attipaci]

The vcpkg port is nearly ready to go (see microsoft/vcpkg#47819). It's just waiting for the finalized v1.5.0 release. Currently, there is one feature option (solsys-calceph), but there probably will be another one for solsys-cspice also...

[attipaci]

And, now it's live on vcpkg. :-)