Fix building library using Ninja #11
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR fixes two issues I ran into while trying to use libASPL for my own project. I have tested it and it should work exactly the same as before on setups where it was already working. Additionally, it fixes compatibility issues with the Ninja CMake generator, and a second minor issue I came across.
1. Making libASPL ninja-compatible
I use Ninja as my default build system, and I prefer using CMake's FetchContent for handling dependencies. Surprisingly, while libASPL works fine with the Makefiles generator, it breaks using Ninja. This is because the conditional logic for the
gencommands will setBYPRODUCTSto an empty string if the files already exist, and Ninja does not allow multiple commands to have the sameBYPRODUCTS.(In fact, this led me down a rabbit hole about how CMake and Ninja interpret the meaning of
BYPRODUCTS. Ninja will invoke the gen commands every time, even if byproducts exist. It will only compare the byproduct's modified timestamps before and after, and cancel re-building the byproduct's dependencies if the file doesn't change -- i.e. the gen command itself must decide if byproducts will be re-built or left as they are.)Anyway I spent a lot of time playing around with the best approach to fixing this, and came up with a refactoring the generation commands into a custom function. Makefile builds still work the same way as before, but Ninja builds that were previously failing now work as well.
2. Providing a fallback when GIT_TAG doesn't match the version-string regex.
When testing out the fix above in my project, I pulled in my fork using FetchContent, e.g. like this:
However, libASPL applies a regex to
GIT_TAGand expects it to be of the formv?([0-9.]+). Branch names like above result in an empty string, which leads to errors because CMake can't "see" empty strings unless they're in quotation marks. I added my fix for this to the PR as well.