feat: nix support

[liamnwhite1]

Summary

This PR makes the installed geometry-central package self-contained for downstream CMake and Nix consumers.

It removes the need for:

• custom downstream FindGeometryCentral.cmake / Findgeometry-central.cmake files
• downstream postInstall copy steps for vendored headers

The changes are intentionally small and split into two logical commits:

1. install and export a proper CMake package
2. install bundled headers referenced by public installed headers

What Changed

1. Export an installable CMake package

This PR teaches geometry-central to install a standard CMake config package under:

• lib/cmake/GeometryCentral/GeometryCentralConfig.cmake
• lib/cmake/GeometryCentral/GeometryCentralTargets.cmake

That allows downstream projects to use:

find_package(GeometryCentral REQUIRED CONFIG)
target_link_libraries(my-target PRIVATE geometry-central::geometry-central)

without providing a custom FindGeometryCentral.cmake.

To make the export work cleanly, the target interface was adjusted so the installed package does not depend on this repository's local helper targets from deps/, while installed consumers still inherit Eigen3::Eigen transitively.

2. Install bundled public dependency headers

Some installed public headers currently reference vendored headers that were not being installed.

This PR installs the missing public dependency headers:

• happly.h
• nanort/nanort.h

so the install tree is usable without downstream postInstall copy steps.

Why

Before this PR, downstream packaging needed extra repository-specific fixes.

In Nix, a working derivation required:

• injecting custom FindGeometryCentral.cmake / Findgeometry-central.cmake files
• copying vendored headers into $out/include in postInstall

After this PR, those workarounds are no longer needed.

Verification

The changes were verified with:

1. A real nix build of the package using:

   • -DGC_ALWAYS_DOWNLOAD_EIGEN=OFF
   • -DGC_EIGEN_LOCATION=.../include/eigen3
   • -DSUITESPARSE=OFF

2. Inspection of the install tree to confirm it now contains:

   • lib/libgeometry-central.*
   • lib/cmake/GeometryCentral/GeometryCentralConfig.cmake
   • lib/cmake/GeometryCentral/GeometryCentralTargets.cmake
   • include/happly.h
   • include/nanort/nanort.h

3. A downstream smoke test that successfully configured and built with:

   • find_package(GeometryCentral REQUIRED CONFIG)
   • target_link_libraries(... geometry-central::geometry-central)

Notes

• This PR does not add broader packaging features like pkg-config files.
• This PR keeps the scope narrow and focused on making the install tree complete and discoverable.
• No public geometry-central API was intentionally changed.
• Once this PR is merged a complete nix derivation can be made for geometry-central.

[nmwsharp]

How does this interact with the system for resolving Eigen from multiple possible sources here https://github.com/nmwsharp/geometry-central/blob/master/deps/CMakeLists.txt#L30-L95 ?

Does this mean we'd immediately error-out if called by a user who lacks Eigen, rather than falling back on downloading it?

[nmwsharp]

Evidently the answer to my question is "no", because the CI tests download Eigen in this way and it still worked.

I guess I need to understand when this line gets executed

[liamnwhite1]

This only runs in the installed-package path, after geometry-central has already been built/installed and a downstream project later does find_package(GeometryCentral REQUIRED CONFIG).

The existing Eigen resolution logic in deps/CMakeLists.txt is still the path used when building geometry-central itself from source, so the fallback/download behavior there is unchanged. That’s why CI could still download Eigen and succeed. It was exercising the source-build path, not the installed GeometryCentralConfig.cmake path.

So the split is:

• source build of geometry-central: deps/CMakeLists.txt resolves Eigen and can still auto-download it
• downstream consumption of an installed geometry-central package: GeometryCentralConfig.cmake runs, and at that point Eigen needs to be discoverable via CMake

I intentionally kept the installed package on the normal find_dependency() path rather than trying to re-run the repo-local download logic from an installed package.

Hopefully this helps!