Initial port of the SuperNOVAS C/C++ library (v1.5.0-rc8) #47819

attipaci · 2025-10-15T12:51:10Z

Hi,

I would like to add the SuperNOVAS C/C++ library to the vcpkg registry. I am the creator / maintainer of SuperNOVAS, and this is my first ever vcpkg PR. (As such mea culpa if I did not get everything right, and I look forward to any guidance you might provide).

This initial PR is for the latest and likely last release candidate for the upcoming v1.5.0 release, expected around November 1 (or perhaps a bit earlier). Thus, this PR is also a final dress-rehearsal to ensure that the upstream is fully ready for vcpkg listing. If there are any issues with the upstream regarding the vcpkg inclusion, please let me know so it may be fixed for the final release. Otherwise, please merge this PR as appropriate, and I will update the package again as soon as the final v1.5.0 is released.

Thanks,
-- Attila

attipaci · 2025-10-15T14:14:15Z

@microsoft-github-policy-service agree

dg0yt · 2025-10-15T16:45:46Z

ports/supernovas/portfile.cmake

+file(REMOVE_RECURSE "${CURRENT_PACKAGES_DIR}/debug/include")
+
+if(VCPKG_LIBRARY_LINKAGE STREQUAL "static")
+    file(REMOVE_RECURSE "${CURRENT_PACKAGES_DIR}/bin" "${CURRENT_PACKAGES_DIR}/debug/bin")


What is removed here?

Hi @dg0yt,

Good question. I copied this from the existing calceph port, which is a dependency. This was in relation to build errors, like:

/home/pumukli/git/vcpkg/ports/supernovas/portfile.cmake: warning: ${CURRENT_PACKAGES_DIR}/debug/include should not exist. To suppress this message, add set(VCPKG_POLICY_ALLOW_DEBUG_INCLUDE enabled) note: If this directory was created by a build system that does not allow installing headers in debug to be disabled, delete the duplicate directory with file(REMOVE_RECURSE "${CURRENT_PACKAGES_DIR}/debug/include")

/home/pumukli/git/vcpkg/ports/supernovas/portfile.cmake: warning: ${CURRENT_PACKAGES_DIR}/debug/share should not exist. Please reorganize any important files, then delete any remaining by adding `file(REMOVE_RECURSE "${CURRENT_PACKAGES_DIR}/debug/share")`. To suppress this message, add set(VCPKG_POLICY_ALLOW_DEBUG_SHARE enabled)

So it's doing what the build errors suggests to do, and they do make the errors disappear...

Anyway, any further insight is much appreciated.

I'm also still having a hard time with the multi-platform builds. (The upstream package builds fine with CMake on Linux, FreeBSD, MacOSX, and Windows -- but the vcpkg does not, especially with the calceph dependency added).

When I enable the calceph dependency, many platform builds fails trying to build calceph. Which seems strange, given the calceph is a fully integrated port that should build for all platforms except uwp based on its vcpkg config...

Without the calceph dependency, I get a build failure on Android, which seems to be a C standard issue. I think I can fix that upstream in the source, but it may require some trial and error to find just what workaround is needed.

PS. Yes, the android build seems to fail due to a known omission in some versions of the android clib. I'll work around that for the next rc (next week probably)...

Patching the upstream and disabling the calceph dependency now results in a clean CI (below)...

existing calceph port, which is a dependency

It is not declared as a dependency. Am I missing something?

It's not a dependency at the moment. But it's a dependency of a feature that is currently disabled, at least until calceph is healthy again. I'll re-enable the feature and the dependency as soon as calceph allows it.

P.S. Thanks for the review! ;-)

attipaci · 2025-10-19T10:14:15Z

Thanks @dg0yt.

I went ahead and made solsys-calceph an add-on feature. I hope I did it right.

(I'm a little confused about default features still. The docs explain how it is used, but not how you define a feature to be 'default'. My guess would be that it's by setting such options in portfile.cmake if no feature was explicitly set -- if so, I'm certainly not doing that...)

BillyONeal · 2025-10-20T13:19:56Z

The generated "usage text" is accurate. See adding-usage for context.

This looks at least plausible to me:

supernovas provides CMake targets:

  # this is heuristically generated, and may not be correct
  find_package(supernovas CONFIG REQUIRED)
  target_link_libraries(main PRIVATE supernovas::supernovas)

supernovas provides pkg-config modules:

  # SuperNOVAS astrometry library
  supernovas

BillyONeal

This is kind of a lot of product code to be touching in a patch. Since you appear to be upstream would you be willing to merge those changes upstream rather than trying to patch them after the fact here?

The problem is that we can't speak to the correctness of, or otherwise maintain, patches with so much product code change.

But for the big patches I would merge this.

BillyONeal · 2025-10-20T13:06:26Z

ports/supernovas/solsys-calceph.patch

+-#include <semaphore.h>
+
+ /// \cond PRIVATE
+#if defined(_PTHREAD_) || defined(__unix__) || defined(__unix) || defined(__APPLE__)


Couple of suggestions on this part of the patch. (This is not 'Billy the vcpkg maintainer' speaking, this is 'Billy the random C++ programmer speaking', if that makes sense)

mtx_Xxx are problematic names to use because those names are in the C standard. This may be resolved if you flipped the order and put the __STDC_VERSION__ >= 201112L branch first.

It's very strange to declare an object-like macro in some branches but function-like macros in other branches. It's clear that this infrastructure only works for 1 argument given the #else branch, so making them all function-like macros seems doable.

You may wish to consider adding something like the following, as long as you don't require your mutex to be a recursive mutex. (I kept your names despite the first comment)

#elif defined(WIN32) #include <windows.h> # define mtx_init (x) InitializeSRWLock(x) # define mtx_lock (x) AcquireSRWLockExclusive(x) # define mtx_unlock (x) ReleaseSRWLockExclusive(x) # define THREAD_SAFE 1 typedef SRWLOCK mtx_t;

Thanks @BillyONeal,

Yes, trying to make mutexes portable is a pain. The C11 threads.h was meant to improve on it, but then clang does not support it, and while mtx_lock() returns int on Linux but void on Windows (apparently). So it's a mess no matter...

As for the first comment, you are right. I'll change the names in the next rc upstream.

The current patches were a proof of concept, really. I'll have these done more properly in the next upstream release candidate (in ~2 days). I'll incorporate your suggestion for the WIN32 version, and also re-think on how to make the 'non-thread-safe' branch better without turning the code into a mess of #if / #else / #endif blocks...

mtx_lock() returns int on Linux but void on Windows (apparently).

A function-like macro doesn't care about the return type :)

As for the first comment, the order should be safe so long as threads.h is not included in the source, other than the appropriate feature branch. (I.e., even though mtx_* are C11 standard, they should only be defined if threads.h is included).

I vaguely recall a general rule saying to not macroize standard library names but I'm not finding it now so 🤷

The current patches were a proof of concept, really.

Sounds good! I see now you said this in the PR description already and I missed it. (Given all our baseline issues last week I'm being paranoid and trying to look at all the things again...)

You are right that the macro doesn't care for the return type, but the original upstream code checked the return values of the mutex lock call, which then failed for the windows builds... It really is walking a tight rope with the mutexes...

I think I'll have one more dress rehearsal with rc8 in ~2 days. Hopefully it will go smoothly. Even so, let's not merge that yet either, but wait for the final 1.5.0 release (around Oct 29). Once ready, I change the PR status to 'Ready for review' and tag you in a note also...

dg0yt

Some nice-to-haves.

dg0yt · 2025-10-20T17:29:31Z

ports/supernovas/cmake.patch

+ include(GNUInstallDirs)
+ include(CMakePackageConfigHelpers)
+ include(FeatureSummary)
+include(FindThreads)


Either

Suggested change

+include(FindThreads)

or

Suggested change

+include(FindThreads)

+find_package(Threads)

find_package sets interface variables for find modules.

It might be just my confusion, but I thought find_package(Threads) needs the FindThreads CMake module (https://cmake.org/cmake/help/latest/module/FindThreads.html). Hence, I thought you need both (as the patch had), but I might be wrong. Perhaps the module inclusion is not needed...

Edit: It seems like it was my misunderstanding of the CMake documentation. FindThreads is just a label for a find_package use case. It's not a CMake module...

dg0yt · 2025-10-20T17:32:28Z

ports/supernovas/cmake.patch

+     )
+
+    if(CMAKE_USE_PTHREADS_INIT)
+        target_compile_definitions(${PLUGIN} PRIVATE _PTHREAD_)


I would generally suggest a unique prefix instead of _.

Suggested change

+ target_compile_definitions(${PLUGIN} PRIVATE _PTHREAD_)

+ target_compile_definitions(${PLUGIN} PRIVATE SUPERNOVAS_USE_PTHREAD)

and similar in the source code. Avoids clashes with third-party public macros, and facilitates grep etc.

Agreed. Will change in upstream, for the next rc....

dg0yt · 2025-10-20T17:34:42Z

ports/supernovas/cmake.patch

+         supernovas
+         ${EPHEM_LIB}
+         ${LIBM}
+        Threads::Threads


Reminder, didn't check:
Using targets is best practice. But this needs to be complemented with find_dependency(<Pkg> ...) (without REQUIRED) in the installed CMake config, at least for static library linkage.

I guess you mean find_package(Threads) without the REQUIRED...

No, I really mean find_dependency which is available after include(CMakeFindDependencyMacro).
https://cmake.org/cmake/help/latest/module/CMakeFindDependencyMacro.html

Sorry, I'm a little confused here (just to show how ignorant I am). The CMake docs on FindThreads has the following example:

set(THREADS_PREFER_PTHREAD_FLAG TRUE) find_package(Threads) target_link_libraries(example PRIVATE Threads::Threads)

Do you mean that I need to add a find_dependency(Threads::Threads) after the find_package() before using it in the target_link_libraries()? If so, I wish the CMake documentation were more accurate on this...

Edit: After some googling, it seems like the conventional way is to add find_dependency(Threads) to cmake/supernovasConfig.cmake.in. Or, do you want it in portfile.cmake also?

In CMakeLists.txt, use find_package. And REQUIRED as needed.

The portfile has vcpkg_cmake_config_fixup, so I assume supernovas exports and installs a CMake config package.
Now when you link to the provided Threads::Threads, it will be referenced in the interface link libraries of export targets (at least for static linkage). (You can inspect the installed files.)

Now downstream users do find_package(supernovas CONFIG REQUIRED).
They do not know that supernovas uses this target. But supernovas does, and it is the CMake config's responsibility to provide this target. It could do find_package(Threads). But getting REQUIRED, QUIET, and diagnostics play well with the capabilities of find_package is a lot of work, and find_dependency is the recommended wrapper doing the job.

portfile doesn't need it. It is just a script in CMake language, not CMake project mode.

That was really helpful thanks. I'm pretty new to CMake, having started with it just about a month ago. So the clarification is really welcome ;-)

I've added find_dependency(Threads) upstream for the solsys-calceph (and solsys-cspice) components. Would you like to check if that looks OK?

https://github.com/Smithsonian/SuperNOVAS/blob/main/cmake/supernovasConfig.cmake.in

Threads is needed only for these optional plugin components. (The solsys-cspice component isn't packaged yet, but I just saw that there is a cspice vcpkg already, so I'll try add that next also).

dg0yt · 2025-10-20T17:35:09Z

ports/supernovas/portfile.cmake

+    REF "v${VERSION}"
+    SHA512 4babecc41fbdfa515f2aea2f07f6b052605d16c1c3d6aa3ab44d13de6cf4ccd1a59f4e72e269623fd4ea73b83b72ff7bd6068c8cb09866a535412e50ee040446
+    HEAD_REF main
+    PATCHES android.patch solsys-calceph.patch cmake.patch


Typical port style:

Suggested change

PATCHES android.patch solsys-calceph.patch cmake.patch

PATCHES

android.patch

solsys-calceph.patch

cmake.patch

The patches will disappear soon, in the next rc...

dg0yt · 2025-10-20T17:35:34Z

ports/supernovas/portfile.cmake

+vcpkg_cmake_configure(
+    SOURCE_PATH "${SOURCE_PATH}"
+    OPTIONS
+        -DBUILD_TESTING=OFF ${FEATURE_OPTIONS}


Typical port style:

Suggested change

-DBUILD_TESTING=OFF ${FEATURE_OPTIONS}

-DBUILD_TESTING=OFF

${FEATURE_OPTIONS}

dg0yt · 2025-10-20T17:35:59Z

ports/supernovas/portfile.cmake

+if(VCPKG_LIBRARY_LINKAGE STREQUAL "static")
+    file(REMOVE_RECURSE "${CURRENT_PACKAGES_DIR}/bin" "${CURRENT_PACKAGES_DIR}/debug/bin")
+endif()


What is removed here?

I'm not 100% sure, except that the static build spat out errors when this was not added.

Perhaps, it is related to the docedit executable created during the build, which just makes a version of the Github README.md that is a more standard standalone markdown. It's just a build-time tool, to remove badges and get rid of github style decorations. It should not be installed (but perhaps it did get installed by CMake).

I'll double check what files CMake installs for static builds, and see if there is something I can do to remedy it upstream...

dg0yt · 2025-10-20T17:36:23Z

ports/supernovas/portfile.cmake

+vcpkg_cmake_config_fixup(CONFIG_PATH "lib/cmake/${PORT}")
+vcpkg_fixup_pkgconfig()
+
+file(REMOVE_RECURSE "${CURRENT_PACKAGES_DIR}/debug/include")


Keeping this together.

Suggested change

file(REMOVE_RECURSE "${CURRENT_PACKAGES_DIR}/debug/include")

file(REMOVE_RECURSE "${CURRENT_PACKAGES_DIR}/debug/include")

file(REMOVE_RECURSE "${CURRENT_PACKAGES_DIR}/debug/share")

dg0yt · 2025-10-20T17:36:50Z

ports/supernovas/portfile.cmake

+file(REMOVE_RECURSE "${CURRENT_PACKAGES_DIR}/debug/share")
+


Suggested change

file(REMOVE_RECURSE "${CURRENT_PACKAGES_DIR}/debug/share")

vcpkg definitely gave errors if without it, and explicitly suggested adding this line...

attipaci · 2025-10-22T12:53:03Z

The additional solsys-cspice feature is currently blocked by PR #47923, which is needed so that the cspice headers are accessible to the feature build here...

attipaci · 2025-10-22T13:25:42Z

Hi @BillyONeal and @dg0yt,

Thank you both for all the work you put into helping this package take shape. The next (and hopefully last) upstream release candidate is now here. All patches are gone, and I have incorporated all your suggestions upstream. The plan is to get this PR ready to merge next week with the final 1.5.0 release. A few outstanding items, questions:

I cannot add a solsys-cspice feature yet, due to the fact the the cspice package does not install the headers properly. I've created a patch in a separate PR [cspice] Install headers under the standard install location #47923. Once that is merged, I'll try again.
My vcpkg.json copies the supports settings from the calcelph dependency. Is that the right thing to do, or does the feature automatically determine which platforms are supported based on the listed dependencies? I.e., if calceph does not support uwp, does that automatically extend to the solsys-calceph feature, or does that feature need to explicitly repeat the "support": "!uwp" directive? (The inheritance would make sense, since if someone changes what platforms the dependency supports, the dependent feature should automatically adapt...)
Let me know if you have any further comments or suggestions before finalizing this PR for 1.5.0 next week.

attipaci · 2025-10-22T21:08:26Z

@dg0yt, Here I try to build against the cspice package (the original before your PR), and I get errors like (see the CI below):

/Users/vcpkg/Data/b/supernovas/src/v1.5.0-rc8-e70a30dfee.clean/src/solsys-cspice.c:111:10: fatal error: 'cspice/SpiceUsr.h' file not found
  111 | #include "cspice/SpiceUsr.h"

Given that cspice seems to install the headers, I'm not sure what's amiss. Maybe you can help me find the reason for the error...

dg0yt · 2025-10-23T02:22:40Z

The line before is the command line:

/usr/bin/cc -DSUPERNOVAS_USE_PTHREAD -I/mnt/vcpkg-ci/b/supernovas/src/v1.5.0-rc8-e70a30dfee.clean/include -fPIC -g -fPIC -MD -MT CMakeFiles/solsys-cspice.dir/src/solsys-cspice.c.o -MF CMakeFiles/solsys-cspice.dir/src/solsys-cspice.c.o.d -o CMakeFiles/solsys-cspice.dir/src/solsys-cspice.c.o -c /mnt/vcpkg-ci/b/supernovas/src/v1.5.0-rc8-e70a30dfee.clean/src/solsys-cspice.c

It doesn't contain -I/mnt/vcpkg-ci/installed/x64-linux (or the -isystem variant) so the compiler won't find cspice headers.

The vcpkg CMake toolchain adds search paths to inform CMake. But it doesn't have magical power to know the right paths and path lists for individual build system targets. This is left to the project's build system. Supernovas' CMakeLists.txt (or a find module) needs to add something like:

find_path(CSPICE_INCLUDE_DIR "cspice/SpiceUsr.h" REQUIRED)
target_include_directories(core PRIVATE "${CSPICE_INCLUDE_DIR}")

And similar for other dependencies.

(The find_path is often handled in Find modules, and you would only use the <Pkg>_INCLUDE_DIRS variable. With CMake config packages, include directories are usually carried implicitly as properties of imported targets.)

attipaci · 2025-10-23T07:16:53Z

@dg0yt,

Thanks for the suggestion. Some progress on the cspice feature inclusion, but the windows dll builds against the cspice lib still fail. It's not clear to me from the logs why (it simply states FAILED with an error code that means nothing to me):

[28/30] C:\Windows\system32\cmd.exe /C "C:\Windows\system32\cmd.exe /C "D:\downloads\tools\cmake-3.30.1-windows\cmake-3.30.1-windows-i386\bin\cmake.exe -E __create_def D:\b\supernovas\x86-windows-dbg\CMakeFiles\solsys-cspice.dir\.\exports.def D:\b\supernovas\x86-windows-dbg\CMakeFiles\solsys-cspice.dir\.\exports.def.objs && cd D:\b\supernovas\x86-windows-dbg" && D:\downloads\tools\cmake-3.30.1-windows\cmake-3.30.1-windows-i386\bin\cmake.exe -E vs_link_dll --intdir=CMakeFiles\solsys-cspice.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100261~1.0\x64\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100261~1.0\x64\mt.exe --manifests  -- C:\PROGRA~1\MICROS~1\2022\ENTERP~1\VC\Tools\MSVC\1444~1.352\bin\Hostx64\x86\link.exe  CMakeFiles\solsys-cspice.dir\src\solsys-cspice.c.obj  /out:bin\solsys-cspiced.dll /implib:lib\solsys-cspiced.lib /pdb:bin\solsys-cspiced.pdb /dll /version:1.5 /machine:X86 /nologo    /debug /INCREMENTAL  /DEF:CMakeFiles\solsys-cspice.dir\.\exports.def -LIBPATH:D:\b\supernovas\x86-windows-dbg\lib lib\supernovasd.lib  cspice.lib  kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib && cd ."
FAILED: [code=4294967295] bin/solsys-cspiced.dll lib/solsys-cspiced.lib

Do you have any insights?

attipaci · 2025-10-23T07:40:17Z

@dg0yt, A separate question. Regarding the file removals in portfile.cmake...

The files removed are effectively the Development component of SuperNOVAS. They would not be installed in the first place if the vcpkg DEBUG build installed with --component Runtime (instead of all available components). However, I cannot find a vcpkg option (e.g. for vcpkg_cmake_install()) to control the CMake install component selection.

For the vcpkg debug builds I can only really set build config variables for OPTIONS_DEBUG in vcpkg_cmake_configure(). Of course, I could add such a build option (e.g. INSTALL_RUNTIME_ONLY), and in CMakeLists.txt install runtime components only when it's set to TRUE. However, given that cmake install --component=Release is a CMake feature that would readily do that, it seems superfluous...

Or, perhaps, sticking with the removals in portfile.cmake is still the best way to deal with this now...

dg0yt · 2025-10-23T07:45:08Z

Similar issue, but now in the link step:

LINK Pass 1: command "C:\PROGRA~1\MICROS~1\2022\ENTERP~1\VC\Tools\MSVC\1444~1.352\bin\Hostx64\x64\link.exe CMakeFiles\solsys-cspice.dir\src\solsys-cspice.c.obj /out:bin\solsys-cspiced.dll /implib:lib\solsys-cspiced.lib /pdb:bin\solsys-cspiced.pdb /dll /version:1.5 /machine:x64 /nologo /debug /INCREMENTAL /DEF:CMakeFiles\solsys-cspice.dir\.\exports.def -LIBPATH:D:\b\supernovas\x64-windows-dbg\lib lib\supernovasd.lib cspice.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST /MANIFESTFILE:CMakeFiles\solsys-cspice.dir/intermediate.manifest CMakeFiles\solsys-cspice.dir/manifest.res" failed (exit code 1104) with the following output:
LINK : fatal error LNK1104: cannot open file 'cspice.lib'

The lib is not given with full path, but there is no effort to provide a search path to the linker.

CMakeLists.txt has

    find_library(cspice cspice REGISTRY_VIEW TARGET REQUIRED)

which sets a variable named cspice to the full path, but links

    target_link_libraries(solsys-${EPHEM_LIB} PRIVATE
        supernovas::core
        ${EPHEM_LIB}
        ${MATH}
        Threads::Threads
    )

carrying the literal cspice in ${EPHEM_LIB}. It is a literal word during cmake generation phase: If it is not the name of CMake target, CMake must assume that it is a namespec, mapping to -lspice for non-MSVC and to spice.lib for MSVC. And then you depend on the linker search path.

But what you actually want is to use the result of find_library. Something like:

    find_library(CSPICE_LIBRARY cspice REQUIRED)
...
    target_link_libraries(solsys-cspice PRIVATE
        supernovas::core
        ${CSPICE_LIBRARY}
        ${MATH}
        Threads::Threads
    )

(Do you really need this plugin function? It might adds complexity when tracing prolems. Perhaps YAGNI.)

dg0yt · 2025-10-23T07:53:29Z

Regarding the file removals in portfile.cmake...

The files removed are effectively the Development component of SuperNOVAS.

By default, vcpkg build two configurations of each port, debug and release.
From the debug build, only binary artifacts (and exported config) shall be kept.
Non-binary artifacts (e.g. include) are usually cheap, so let the build system install it, and let the portfile cleanup, after cmake config fixup.

There are release-only triplets which skip the debug build.

And Development != Debug.

attipaci · 2025-10-23T08:07:54Z

(Do you really need this plugin function? It might adds complexity when tracing prolems. Perhaps YAGNI.)

I guess not. I just thought it might be nice to add the feature given that there is a cspice vcpkg, but given the complications it may not be worth it, especially given that calceph provides very similar functionality overall. (The only cspice specific use case I can think of is if an application already uses cspice, and wants to add additional functionality via supernovas -- in which case it would make sense to stick to cspice for supernovas also.)

dg0yt · 2025-10-23T09:14:15Z

(Do you really need this plugin function? It might adds complexity when tracing prolems. Perhaps YAGNI.)

I guess not. I just thought it might be nice to add the feature given that there is a cspice vcpkg

I was refering to the custom cmake function handling plugins in the build system, not to the cspice feature/plugin. I often encounter such convenience functions when tracing problems, and it can be a PITA to find out how they are meant work and how to make them work. Just another layer of indirection.
Here, the problem is the use of the EPHEM_LIB parameter for the target name (okay) and as a link library name (not okay). (It might be used to construct a variable name or target name which resolves to actual link libraries (plural), but I didn't really want to deal with cmake function.)

attipaci · 2025-10-23T09:29:27Z

@dg0yt,

I see. Without the function I'd have repeated blocks of the same code -- notwidthstanding the library name (cspice / calceph). I see your point about tracing errors, but I really despise repeated code blocks, since if one wants to change some part of it, there is high chance that one either forgets to update all occurrences, or else that the changes won't end up being exactly the same among the occurrences. It's a common source of stupid errors, which the use of a common function eliminates entirely...

Anyway, I've made changes upstream again to use find_path() and find_library(). For now, I'll ignore the cspice feature for the port, but will revisit it again in the future, perhaps as soon as next week after the release...

attipaci force-pushed the supernovas branch 6 times, most recently from 7eea519 to f2ec923 Compare October 15, 2025 14:13

attipaci force-pushed the supernovas branch 8 times, most recently from bfb8d5b to 165c32f Compare October 15, 2025 14:51

dg0yt reviewed Oct 15, 2025

View reviewed changes

attipaci force-pushed the supernovas branch 14 times, most recently from b4bdd70 to 4869ba9 Compare October 15, 2025 20:24

Separate solsys-calceph feature

136d11c

attipaci force-pushed the supernovas branch from aac84b1 to 136d11c Compare October 19, 2025 08:27

BillyONeal reviewed Oct 20, 2025

View reviewed changes

BillyONeal added the category:new-port The issue is requesting a new library to be added; consider making a PR! label Oct 20, 2025

dg0yt reviewed Oct 20, 2025

View reviewed changes

attipaci force-pushed the supernovas branch 7 times, most recently from f8b4471 to f1963cf Compare October 22, 2025 12:37

Upstream v1.5.0-rc8

3982d5d

attipaci force-pushed the supernovas branch from f1963cf to 3982d5d Compare October 22, 2025 12:37

attipaci force-pushed the supernovas branch from 3c9650b to 3f7ee44 Compare October 23, 2025 06:57

attipaci force-pushed the supernovas branch from 3f7ee44 to 3982d5d Compare October 23, 2025 08:08

attipaci changed the title ~~Initial port of the SuperNOVAS C/C++ library (v1.5.0-rc7)~~ Initial port of the SuperNOVAS C/C++ library (v1.5.0-rc8) Oct 23, 2025

	+ target_compile_definitions(${PLUGIN} PRIVATE _PTHREAD_)
	+ target_compile_definitions(${PLUGIN} PRIVATE SUPERNOVAS_USE_PTHREAD)

	-DBUILD_TESTING=OFF ${FEATURE_OPTIONS}
	-DBUILD_TESTING=OFF
	${FEATURE_OPTIONS}

	file(REMOVE_RECURSE "${CURRENT_PACKAGES_DIR}/debug/include")
	file(REMOVE_RECURSE "${CURRENT_PACKAGES_DIR}/debug/include")
	file(REMOVE_RECURSE "${CURRENT_PACKAGES_DIR}/debug/share")

Initial port of the SuperNOVAS C/C++ library (v1.5.0-rc8) #47819

Are you sure you want to change the base?

Initial port of the SuperNOVAS C/C++ library (v1.5.0-rc8) #47819

Conversation

attipaci commented Oct 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

attipaci commented Oct 15, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

attipaci Oct 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

attipaci commented Oct 19, 2025

Uh oh!

BillyONeal commented Oct 20, 2025

Uh oh!

BillyONeal left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

attipaci Oct 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

attipaci Oct 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dg0yt left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

attipaci Oct 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

attipaci commented Oct 15, 2025 •

edited

Loading

attipaci Oct 15, 2025 •

edited

Loading

attipaci Oct 20, 2025 •

edited

Loading

attipaci Oct 20, 2025 •

edited

Loading

attipaci Oct 20, 2025 •

edited

Loading

attipaci commented Oct 22, 2025 •

edited

Loading

attipaci commented Oct 22, 2025 •

edited

Loading

dg0yt commented Oct 23, 2025 •

edited

Loading