Not an issue, just an addition to the Windows with Visual Studio 2022/2026 build

[laheller]

Hi @attipaci

Just a note to the build on Windows platforms with Visual Studio 2022 or newer:
To even easier build SuperNOVAS, from the Developer command prompt for VS we can run (example):
cmake.exe -DBUILD_SHARED_LIBS=ON -DBUILD_EXAMPLES=ON -G "Visual Studio 17 2022" -A x64 -T v143 ..
where the -G -A -T parameters are defining the Generator, Platform and Toolset respectively and .. is of course the path to the folder, where the main CMakeLists.txt file lives.

By running the above command, cmake also generates a Visual Studio solution file supernovas.sln that can be then opened in the Visual Studio and simply execute the build. Tested with SuperNovas v1.5.1, it works perfectly: One CLI command and then one click in VS, everything is built!

Additional note:
I started to create C# language bindings for the SuperNOVAS library so that it can be used on .NET platforms. Once done/tested, will let you know.

BR,

Ladislav

[attipaci]

Hi @laheller,

Thanks for the tip. I'll add it to the README. ;-)

Maybe there is a way to add the -G -A -T options to the vcpkg build also. If you have an idea how to, feel free to explore that too. It's beyond me...

As for the C# bindings, you might want to take a look at PR #256, which is my ongoing attempt to add a higher-level C++ API on top of the C99 one. Presumably C# is closer to C++, so you may want to bind to that rather than to the lower-level C99 API. Or, you may follow a different path for C#. As I'm no expert on C# (or anything Windows really), I leave it to you to do what you think best. In any case thank you for doing it, and I look forward to the C# bindings when they are ready!

PS. I converted this to a discussion if you don't mind.

[laheller]

Hi @attipaci

Just for my information, whether I understand correctly:
Are you going to just extend SuperNOVAS by the C++ API while keeping the old C99 API,
or do you plan to replace the C99 completely with C++?

BR,

Ladislav

[attipaci]

Extend.

The idea is that the supernovas library remains to provide the C99 API, and there will be a supernovas++ library in addition, which provides the C++ API (under the supernovas namespace), as well as the C API (under the novas namespace). Users can then use either of these, depending on what suits their needs better.

The two libraries (supernovas and supernovas++) will provide the exact same algorithms, just in different clothing...

[attipaci]

@laheller,

Slowly digesting your original message. Would you like to submit the supernovas.sln (in the appropriate directory) as a PR? I'm thinking that this way anyone else working on SuperNOVAS in VS can build it with a click, like you describe. Or is in not as universal?

P.S. I am using Eclipse CDT for the development, and I do commit the Eclipse configs for the project so that anyone else using Eclipse can have the environment readily configured for it. It would make sense to include similar ready-to-go configs for other IDEs, such as VS, also...

[laheller]

@attipaci

I can send it you, but as you said, it's not universal and not the only VS-related file generated by cmake.
A single VS solution (.sln) file is not enough, it just holds some information about the more important VS project files (in case of a C-language project with the extension .vcxproj). Those project files then directly describe, what C-source files, header files and what symbols, compiler/linker settings are needed to build the project.
Also the number of genereted VCXPROJ files depends on the SuperNOVAS cmake build options (like for example BUILD_SHARED_LIBRARY, BUILD_EXAMPLES).

In github also you can create/add an additional workflow (I saw you already have some) of type msbuild which in combination with a cmake-type workflow step could build the generated VS solution/projects and provide directly the supernovas.dll binary file (shared library on Windows platform).

What I can do is to generate the solution/project files using all possible SuperNOVAS build options (however I don't know, whether the optional dependencies like CALCEPH or CSPICE is even possible to build on Windows) and send it to you....
...zipped via email?

BTW, your real name suggests that you are hungarian. Is that true? I am asking because I'm too 🙂

BR,

Laci

[attipaci]

Szia Laci! Igen, en is magyar vagyok. Es koszi elore is... ;-)

[laheller]

@attipaci

One quick finding that when cmake generates the solution file & project files, it always puts absolute paths inside those files which can easily lead to errors. I am going to check first, whether relative paths (relative to the SuperNOVAS repo root) are supported. If so, I will edit/test the generated files and when everything is OK, send it to you.

Laci

[laheller]

@attipaci

It seems, it's not possible to make those generated project files "portable". Some of the absolute paths I changed to relative worked, but some of them not and the build failed. But anyway, what you can try is to add a new github workflow that runs the below commad:
cmake -DBUILD_SHARED_LIBS=ON -DBUILD_EXAMPLES=ON -DBUILD_TESTING=ON -DBUILD_BENCHMARK=ON -G "Visual Studio 17 2022" -A x64 -T v143 ..
...followed by an msbuild-type workflow that takes the soultion file generated at the previous workflow and builds everyting.

Laci

[laheller]

Hi @attipaci

I just forked SuperNOVAS repo and created a new workflow to demonstrate the cmake and Visual Studio build for Windows:
https://github.com/laheller/SuperNOVAS/actions/workflows/cmake-windows.yml

The workflow also provides the built supernovasd.dll (with the letter d for Debug build) shared library as an artifact for downloading, so one can easily download & test the SuperNOVAS library. This way it's really not necessary (and I think is not even possible) to add a working & universal Visual Studio solution/project files to the repository.

Test run with the artifact is here:
https://github.com/laheller/SuperNOVAS/actions/runs/20789698348

Another topic, the C# language bindings creation is still in progress. Should I came with a PR, once done? If yes, what repo structure you suggest? At the end the result of my work would be probably only two source files (+ a readme):

• SuperNOVAS.cs - the C# language bindings, the wrapper around the C-language functionality
• Test.cs - sample program about how to use the C# language bindings

BR,

Laci

[attipaci]

Hi Laci,

Nice, I'll take a look at it tomorrow. +1

I think for the C# bindings, it might make more sense to make them into a repo of their own (e.g. supernovas-csharp). In my mind the bindings to other languages are add-ons (dependent projects).

You can then either make the SuperNOVAS C repo as a dependence of the build (e.g. supernovas package dependence for CMake), and the Github workflows (check out SuperNOVAS in the yml along with your repo).

If that would not work for some reason, alternatively you can make the SuperNOVAS repo a submodule of your C# bindings repo. Depending on what you are thinking, the submodule route may be a blessing or a curse. The nice thing about submodules is that you control exactly what version (commit or tag) of the SuperNOVAS submodule you reference for the bindings (so you can be sure that upstream work does not mess things up in unwanted ways). The bad things is that you have to sync (update) the submodule regularly (e.g. for each SuperNOVAS release) if you do want to keep up with the upstream...

These are just a suggestion. We can haggle over it more... :-)

-- A.

[attipaci]

Szia Laci! Olvastam az emailedet (a telefonon), utana viszont mar nem talaltam. Mintha a gmail eltuntette volna. Kuld el megegyszer legyszi, hogy meglegyen a cimed es tudjak valaszolni... -- A.

[laheller]

@attipaci
Küldtem.