Provide _INCLUDE_DIR in cmake_find_package generator #6017
Conversation
| @@ -58,8 +58,13 @@ def _find_for_dep(self, name, cpp_info): | |||
| # Here we are generating FindXXX, so find_modules=True | |||
| public_deps_names = [self.deps_build_info[dep].name for dep in cpp_info.public_deps] | |||
| lines = find_dependency_lines(name, public_deps_names, find_modules=True) | |||
| # get {{name}}_INCLUDE_DIR as a first include path if exists | |||
| if cpp_info.include_paths: | |||
| include_dir = cpp_info.include_paths[0] | |||
There was a problem hiding this comment.
It seems a bit arbitrary that just the first path is used. Can't INCLUDE_DIR variable contain more than one path?
There was a problem hiding this comment.
Good point, it can have more than one path. That's because cmake encourage a user to use INCLUDE_DIRS. Usually, it will work but multiple paths can be found by complex modules such as FindJava and FindFreetype.
I think we can provide a list as a string joined by semicolons (as recommended in forums and some modules):
set(FREETYPE_INCLUDE_DIRS "${FREETYPE_INCLUDE_DIR_ft2build};${FREETYPE_INCLUDE_DIR_freetype2}")There was a problem hiding this comment.
Added a commit that builds a string from all include paths. It is very common with INCLUDE_DIRS but semicolon-separated because I think consuming packages can be surprised by a newline-separated list in INCLUDE_DIR.
There was a problem hiding this comment.
I don't like it much, I think it is a bit complex the new variable and the replacements. What if we generate INCLUDE_DIR when there is only one include dir only? @memsharded Rarely the packages declare more than one, and in these cases, they are managing INCLUDE_DIRS anyway...
There was a problem hiding this comment.
The original variant of PR generated a variable with the first include directory only and it covered 99% cases. But I thought it would be better to support remaining cases. If the former variant is more clear, I can revert the second commit.
Unfortunately, the problem is not in a package that produces variables (it will provide INCLUDE_DIRS for multiple directories of course) but in a bad-written package that consumes those variables. Many real-world packages use old-style _INCLUDE_DIR instead of INCLUDE_DIRS, even if there is only one directory.
Just for information, in case of a single include directory the generated cmake file will contain two same definitions:
set(LIBFOO_INCLUDE_DIRS "/path/to/included/dir")
set(LIBFOO_INCLUDE_DIR "/path/to/included/dir")For two directories:
set(LIBFOO_INCLUDE_DIRS "/path/to/included/dir"
"/path/to/included/dir2")
set(LIBFOO_INCLUDE_DIR "/path/to/included/dir;/path/to/included/dir2")| if cpp_info.include_paths: | ||
| include_dir = cpp_info.include_paths[0] | ||
| else: | ||
| include_dir = '""' |
There was a problem hiding this comment.
What if include_dir is just empty instead of ""? The final var:
set(ZLIB_INCLUDE_DIR) # Good
#no need of
set(ZLIB_INCLUDE_DIR "") There was a problem hiding this comment.
This may be not actual with a new commit that uses all include paths
Variable _INCLUDE_DIR may be expected to be a pure string (without newlines). So build it as semicolon-separated string that is essentially a CMake list.
|
@lasote thanks, that looks really better! I doubted about introducing new attributes in |
|
No, it is not the same model. The CMake one is just a wrapper for preparing the cppinfo data to something more chewed for the cmake generators. |
|
ah, yes, confused by the similar name |
Changelog: Feature: Provide
_INCLUDE_DIRvariables in thecmake_find_packagegeneratorDocs: omit
This affects at least ZLIB (a lot of package check ZLIB_INCLUDE_DIR), openjpeg.
Closes: #6011
developbranch, documenting this one.Note: By default this PR will skip the slower tests and will use a limited set of python versions. Check here how to increase the testing level by writing some tags in the current PR body text.