Open friendlyanon opened 2 years ago
Hmm, I thought about the pkgconfig code and it's actually not quite right as it is now either.
The problem with generating a pkgconfig file via CMake is that it does not fit the model of CMake. The prefix
variable has to be absolute in the .pc file, however CMake deals with paths relative to the prefix. The final prefix can change at all times, via CMAKE_INSTALL_PREFIX
, --prefix
parameter during install time, at CPack time and the resulting deb/rpm files can be extracted anywhere as well. If one needs a pkgconfig file for packaging purposes, both deb and rpm CPack generators allow the user to add post-install scripts that can generate it if necessary.
As a clarification: the case where the user is installing with cmake --install
or the install
target both work fine, but packaging is where things break due to the prefix
variable needing to be absolute in the .pc file.
It seems that when you run
cmake .
make test
You are correct. The project doesn't use the normal test mechanisms for whatever reason.
Note the lack of add_test
calls. I think that could be added to this PR as well, since that fits the topic.
I will rebase the first commit and add the appropriate changes there.
I cleaned up things around the CPack config and pkgconfig.
The CPack config with the project specific defaults is configured to the CPack(Source)Config-ctre.cmake
file in the root binary directory. These files include()
the CMake generated ones and overwrite some values with set()
calls. Using these files can be done with cpack --config ...
.
The .pc file now uses the configure time CMAKE_INSTALL_PREFIX
variable to get its prefix
value. This makes it possible to anticipate ahead of time where the generated package files will be installed to. There is a warning emitted during the very first configuration if the pkgconfig option is enabled without CMAKE_INSTALL_PREFIX
also being set. If the project is installed with cmake --install ... --prefix ...
however, then the .pc file will contain the wrong prefix. This sould probably be documented in https://github.com/hanickadot/compile-time-regular-expressions/pull/231 cc @angeletakis
@friendlyanon Will do 💯
This commit does a couple changes:
Unspecified
one