Proposing CMake Build-System Updates

[mabruzzo]

Following up on our discussion from grackle-project#193, I wanted to suggest some changes to help reconcile the difference between our implementations of the cmake build-system (as a reminder, my version is found in grackle-project#182).

As I've previously mentioned, I think the stuff that you are doing is fantastic, and I definitely don't want to get in the way of your progress (if it's more convenient for you, we can always put off dealing with these differences until a later date).

Overview

I'll now provide some basic details about the changes I am proposing here. There are 2 parts of this changeset that are worth highlighting:

1. this proposed-changeset builds on changes that are proposed as part of my Factor out some file-generation machinery grackle-project/grackle#181 pull request
   • that PR (181) overhauled a bunch of the file generation machinery (using the old build-system). It drastically simplifies the process of auto-generating files with cmake. (this is where the config/*.py files come from.
   • that PR (181) is awaiting some final review before it gets merged into the main-branch. Based on my conversation with Britton, it sounds like his going to approve it (I've already made some changes he requested)
2. this proposed-changeset essentially merged in the changes from my Introducing Experimental Supplementary CMake Build System grackle-project/grackle#182 pull-request
   • that PR (182) is where I introduced my version of the cmake build-system. It already includes the changes from (181)
   • as I've noted elsewhere, that PR was originally written with the intention of letting us embed Grackle inside of other CMake projects. A number of naming choices were made to help facilitate this goal, such as:
     • a bunch of public-facing variables are prefixed with GRACKLE_
     • the main library-target is called Grackle::Grackle (this is standard convention for names of imported targets)
     • machinery is put in place to disable some stuff when the Grackle-build is embedded inside another cmake project (i.e. grackle is not the top-level cmake project)
     • a lot of the design choices were influenced by this book
   • Overall, I placed a lot of emphasis on compatibility with existing tests and the results produced by the existing build-system
     • the python bindings can now efficiently be built again (CI tests have been adjusted to run with the python tests)
     • the build-system doesn't force grackle to be a static library. This is still the default behavior, but now users can explicitly opt into using shared libraries (e.g. for use with python bindings) with via the standardized cmake BUILD_SHARED_LIB variable
     • when compiling a shared library (for use with grackle tests), a pseudo-makefile is produced to let the python test run through the examples
     • (there is also the option to compile with openmp - primarily for testing versions)
   • a couple of other relevant changes:
     • hdf5 linking now works more effectively.
     • files are now auto-generated correctly
     • the testable_grackle target should now be used for building unit tests (this is functionally identical to the main Grackle::Grackle target -- it just exposes an extra macro definitions necessary for some unit test)

Let me know if you are unhappy with any of these changes. I'm happy to iterate.

Other stuff

The changes to website-documentation that I added here are somewhat outdated (i.e. it presents cmake as a secondary build-system that supplements the older classic build system). You should probably just ignore it for now. I need to update that more, but I didn't want that to delay me from proposing this changeset.

For better or worse, I also reintroduced files associated with the old build-system

• the main purpose of these is to just let you merge your changes into the upstream repository more easily/frequently/quickly (I don't think the community is quite ready to part with the old build-system quite)
• you definitely don't need to worry about supporting your new tests on the old build system (and once you start working on the GPU porting, you definitely don't need to worry about the old build-system)

Out of curiosity, how do you typically invoke the unit-tests and functional-tests? (While I've worked with Google Test, I've never used it with CMake before). I would love to add these tests to the continuous integration file.

Closing Thoughts

Honestly, the number of files changed may seem a little overwhelming. If I were you, I would just focus on the changes to the cmake files. Most of the remaining changes relate to reintroducing old build-system files.

Again, I want to re-emphasize, that I want to make this all as easy for you as possible.

Let me know if there's something that I can do to help with this process

• For example, if you would prefer that I only propose changes to the smallest subset of files necessary (e.g. remove the old build-system files again), I can do that fairly easily.
• If you would prefer that I propose these changes to your test_implementation instead I can do that
• If you would prefer a cleaner commit history, I would be happy to accommodate that as well (now that I've done this reconciliation once, it will be easy to do it again).