Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add the first target and test (#258)
`stdx` has no dependencies, so it's a good choice for our first target. We make an `INTERFACE` target, using `FILE_SET HEADERS` for more modern handling. By trial and error, it seems like the right move is to set the `BASE_DIRS` to the main project folder. The following other choices are supported by reading the docs (i.e., Professional CMake, 18th Edition), specifically, section 16.2.7 on File Sets: - When we say `FILE_SET HEADERS`, we do not need to provide `TYPE`. - Providing relative paths is correct, because they will be taken to be relative to `CMAKE_CURRENT_SOURCE_DIR`. We also take advantage of section 32.6, "File Sets Header Verification". The `CMAKE_VERIFY_INTERFACE_HEADER_SET` variable (which we also reflect in our docs) will automatically generate synthetic targets that make sure we got our include paths correct. We can "run" this "test" by building the target `all_verify_interface_header_sets`. This is how I figured out what to set `BASE_DIRS` to. On the googletest side, I followed the docs. We use `FetchContent`, but fall back to `find_package` in case there's a system-installed version. This latter behaviour seems highly suspect to me, but the docs were adamant that this is typically the right move, especially for open source projects. See Section 39.8 ("Recommended Practices"). It feels like it would be nice to _at least_ set a minimum version that we would accept from the `find_package` fallback, but we can probably defer that until we get an actual problem report. (And, honestly, maybe there's simply no use case for this anyway? People who want to develop the tests can use `bazel`, which for Au supports a zero-install setup. And people who just want to depend on Au via CMake don't really need to run the tests.) Another consideration is _conditionally_ enabling the GoogleTest dependency, as was done for the branch with the initial CMake support. I would like to defer adding that complexity until we encounter a concrete use case that's blocked by it, so I can be sure I understand why we would want to do that. It turns out that we can "build-and-run-all-tests, incrementally" with a single CMake command that builds three named targets: all, "all header verifications", and test. I updated the instructions to include this. Finally, it appears that running the tests can sometimes create a folder called `Testing`, so I added that to `.gitignore`. Future PRs will add a bunch more targets. Helps #215.
- Loading branch information