Closed compnerd closed 3 years ago
requiring the commonmark developer to explicitly invoke cmark_add_compile_options on the target to ensure that the flags are propagated for the targets without using the generator expression
Not sure what you mean by this...do you mean that the standard build instructions won't work any more (something else needs to be done?)
Not sure what you mean by this...do you mean that the standard build instructions won't work any more (something else needs to be done?)
Correct. You will find that every instance of add_executable
and add_library
(except the aliases) are now followed by a call to the new function. Because it is a custom function, this is something that isn't in the official CMake documentation and needs to be enforced by the project. This is something that anyone adding new libraries or binaries to this project would need to be aware of.
I don't think I made myself clear enough. What I'm asking about is whether the procedure for a user to build and install this library using cmake would be any different as a result of this change?
Oh, from the user's perspective everything remains the same as before.
Thanks.
The
COMPILE_LANGUAGE
generator expression was introduced in CMake 3.3. Debian Jessie has an older CMake version bundled, which prevents building on that platform without manually building CMake. This uses a more error-prone mechanism of requiring the commonmark developer to explicitly invokecmark_add_compile_options
on the target to ensure that the flags are propagated for the targets without using the generator expression. Adding the options unconditionally prevents using CMark in a build with a non-C programming language.Fixes: #384