I honestly prefer this a little to the modified Makefile. Maybe we could do both? I like the pkgconfig and module-based plugin feature of this.

I think both. :-)

It might be worth adding a final check after the Cmake install in the CI. I'd suggest to compile and run examples/example-star.c. This need not be done through a makefile. A simple line of

This was a good recommendation, as I did mess up some things! I was trying to be clever with private/public exports but didn't quite do it right, so trying to link the examples failed miserably haha.

I just checked the calceph integration too (as I think I'll need that!) And it seemed to work (after I made the path just de440s.bsp so I could grab the binary and put it next to the executable to test.

@kiranshila, Would you be willing to add the option for CSPICE integration also? It's unlikely that CSPICE will ever have a CMake config, but people might install the library for their own use otherwise, and so CMake should have the option to build SuperNOVAS with the libsolsys-cspice plugin library also... I'm OK not testing it (definitely cannot do that easily in the CI). If it's not working, someone will eventually speak up... :-D

Hi @kiranshila,

Also, one more request. Could you add a section in the README.md on how to build with CMake, including the configuration options? Something similar to the existing build section (for the Makefile). You can add it before or after (I will probably re-organize the whole build section anyway after the merge)...

Hi @kiranshila,

Also, one more request. Could you add a section in the README.md on how to build with CMake, including the configuration options? Something similar to the existing build section (for the Makefile). You can add it before or after (I will probably re-organize the whole build section anyway after the merge)...

I added a README_CMAKE.md in this PR. I can incorporate that into the main README if you'd like.

@kiranshila, Would you be willing to add the option for CSPICE integration also? It's unlikely that CSPICE will ever have a CMake config, but people might install the library for their own use otherwise, and so CMake should have the option to build SuperNOVAS with the libsolsys-cspice plugin library also... I'm OK not testing it (definitely cannot do that easily in the CI). If it's not working, someone will eventually speak up... :-D

If I can figure out how to install it 😅

More on this - I'm trying to figure out a way to make this work without mucking with the CSPICE installation. Just following the install docs from JPL creates a directory structure that's like cspice/include/SpiceUser.h - but that is at odds with the "cspice/SpiceUsr.h" in solsys-cspice. As far as I can tell, a standard installation would not create that cspice folder in include. This agrees with, say, the Arch linux package (which is maintained by someone at JPL, after all). So, I'm not sure the best way forward.

Also, it is supremely frustrating that they don't name the file libcspice, so -lcspice fails. So some kind of custom user-intervention is required to rename the library, or you use -l:cspice.a

I might try to first patch the Makefile to support both your custom installation, which makes things sensible, or to support just pointing to the folder where the build is.

I have a repo Smithsonian/cspice-sharedlib, which lets you build cspice as a .so library, if that helps. Again, don't bother with the CI for that. If you can make it work locally, or in a vm, that's good enough for that bit...

My bad, I missed the README_CMAKE.md. That's perfect. No need for more. 👍

I have a repo Smithsonian/cspice-sharedlib, which lets you build cspice as a .so library, if that helps. Again, don't bother with the CI for that. If you can make it work locally, or in a vm, that's good enough for that bit...

Right, I guess what I mean is - the way the cspice integration is written requires something custom like your sharedlib. I can't just download CSPICE, build according to their instructions, and link into supernovas. Using cspice requires I do something custom, be it move the includes into a folder named cspice, rename the static lib, etc. It would be possible to have another make def like CSPICE_DIR or something to just point to the vanilla installation and set -l:cspice.a and an ifndef CSPICE_DIR #include <SpiceUsr.h> and so on before we check if there's a more standard posix installation that resulted from something custom.

Indeed, cspice will always be a custom thing. Its licensing does not permit for much in the way of redistribution... So, perhaps we won't support it with cmake. That's perfectly okay. Those who installed cspice (somehow) will have the option of the good old Makefile to compile SuperNOVAS against it.

Hi @kiranshila,

Thanks again for all that good work on build configs.

I was wondering if you would be up for adding a build option (e.g. BUILD_APIDOC=ON|OFF (default: OFF) for the CMake config (as a separate PR)? If it's configured ON, then build the documentation also with doxygen (same as the local-dox target in the GNU Makefile), and then let cmake install install it in the standard location for package docs (e.g. /usr/share/doc/supernovas/). This would allow using CMake to create a more complete package.

A test build (without coverage tracking) might also be useful, but it's less critical from a packaging point of view...

Yeah I can try!

Thanks for improving this! I'm out of the country for this week and next, I can get back to helping once I return.