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.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use standard CMake constructs to export the library's targets. #260
Use standard CMake constructs to export the library's targets. #260
Changes from 1 commit
8e157d1
5b1beab
8ee4c22
e85d2d8
b8d27cf
8acaf91
1cff028
0551a75
7514b61
b66f049
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
INSTALL_DESTINATION
implies an installation action.Either no
INSTALL_DESTINATION
here, or noPCRE2_CONFIG_OUT
two lines later.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had tried removing the
install
below, the file does not get copied.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wouldn't this change the output directory from cmake to "cmake/pcre2"?, does that make a difference?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes it's a regression (thanks for catching it!), but I don't think it would have any impact; it is one of the paths
find_package
will search.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could you verify that it doesn't have an impact?, is there a minimum cmake version that will be needed to include those extra paths?
no idea why it was set that way originally but the change is somehow recent with 2410fbe by jwsblokland
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The earliest CMake version I found that specifies this path for both Windows and Unix is 3.7. For reference the minimum CMake version that Google supports is 3.13 (the earliest version that ships in a supported Linux distribution).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW, I am not advocating to use cmake 3.3 forever (indeed, if you look at the git log, I'd been quietly rising it from 3.0, as new features were used), just making sure that if we are going to say that is the minimum version supported, it actually is.
One interesting thing I noticed after installing cmake 3.3.2 and doing a deployment is that the original code actually puts those 2 files in
${INSTALL_PREFIX}/cmake
, so I wouldn't be surprised if whoever is using this might be adding that special path somehow already and therefore will get a nasty surprise when it goes away.I am testing in a Fedora 38 system, so maybe it is different in Windows and they might be using that and it might work based on your reading of the documentation, but either way it is not a backward compatible change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where can we document this change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally, the code will be changed to be backward compatible so there is no need to document it.
Otherwise, we need to make @PhilipHazel aware so it is mentioned in the ChangeLog and he includes a note of it for the next release announcement. It might even force us to do first a RC release since whoever might be affected will need to make sure to update their code first.
In this case I am sympathetic to the change, since it is likely to work by default and is more consistent, although it might require setting
FIND_LIBRARY_USE_LIB64_PATHS
in some cases.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are discussing the install location of the CMake config file, which is the key to locating the package.
For sane values of
CMAKE_INSTALL_LIBDIR
in relation to the prefix, both the old and the new location is searched byfind_package
Config mode, also in version 3.3, and regardless of operating system:The old location matches
<prefix>/(cmake|CMake)/
.The new location matches
<prefix>/(lib/<arch>|lib|share)/cmake/<name>*/
.Given that exported configs usually consist of several interacting files (config, version, targets, per-config details), this change is necessary and expected, in order to organize the files in a local unit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree the change seems to be in the right direction (specially for *NIX), but we are likely going to need something to put in the release announcement so that anyone that might be affected, is aware of the change and can do whatever change might be needed on their side.
Our old code, wasn't very friendly to multiarch systems or cross compilation because it was installed in such a generic location, but that path was specifically chosen for some reason I am not aware of, so the least we could do is check with the author and come with some scenarios for a migration (if needed).
This file was deleted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shouldn't this have REQUIRED?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It wouldn't play well if pcre2 itself is not REQUIRED.
find_dependency
will put REQUIRED if the requesting package is.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This a key thing about CMake config search mode, even for
find_package(pcre2 REQUIRED)
:With
REQUIRED
, configuration would fail immediately. This isn't desired.If a dependency isn't found, only the current config shall be ignored, and the search for a suitable config shall continue in other locations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Before adding a target in a config file, you must check that it doesn't already exist - a config file may be included multiple times via transitive usage.
(Note that the use of ALIAS is not entirely without problems - there are some scope issues. On the user side, a mitigation is the use of
IMPORTED_GLOBAL
(since CMake 3.11). The alternative are INTERFACE targets.)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will add a check. Should I also add an
include_guard
?Or
find_package(PCRE2 GLOBAL)
, right?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinking of removing this logic. The dependency of
POSIX
to8BIT
is expressed in target dependencies, and the fatal error might interfere with CMake keeping searching to other locations.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here, you are removing the output variable interface. While it is legacy CMake (in contrast to targets), it is unclear if some users still rely on it.
However, it is also unclear which variables form the public interface. IMO it is at least:
PCRE2_LIBRARIES
(subject to components)PCRE2_INCLUDE_DIR
maybe also
PCRE2_${component}_LIBRARY
.I would recommend to at least place the target names in the lib variables. (This still leaves room for incompatibilities but common cases would be covered.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I set the library variables to the library paths.