My actual library has something like 10 optional dependencies depending on cmake options and the return values of find_package.
Basically my first solution works provided you never use generator expressions or imported targets. But that’s not modern cmake
OK, that should also a CMake variable:
PNG_LIBRARIES
Yep. That’s the only solution I can find. Not very modern cmake though
You will have the same problems when exporting a CMake config package
:
you have to write the find_dependency()
calls.
Yep it’s pants.
But at least it’s doable.
I’m starting to believe cmake doesn’t solve anything. As in, it doesn’t actually make you productive. But anyway, it’s the best we got unfortunately
Everything is possible.
Perhaps you should try the project_options
You may write a patch to export a pgk-config
files too?
Es ist nicht genug zu wissen, man muß auch anwenden; es ist nicht genug zu wollen, man muß auch tun.
Johann Wolfgang von Goethe (1749 - 1832)
To be honest, the amount of time I have to spend writing and debugging cmake it’s barely worth it. New languages put a lot of effort in their build tools to minimise the amounting of time spent writing build code.
I might have a look at Meson this weekend and see how they tackle dependencies and install scripts.
But anyway, thank you for all your help
- GitHub - boost-cmake/bcm: Boost cmake modules
- GitHub - robotology/ycm: YCM (YCM CMake modules) is a collection of various useful CMake modules.
provide some wrappers that automatically generate pkgConfig files. I haven’t tried them myself but could be a good resource.
Peter, did you find a solution, I have exactly the same problem as you - a huge number of dependencies, could be shared, could be static, could be coming from conan, could be coming form the system
No I didn’t sorry. I haven’t tried GitHub - boost-cmake/bcm: Boost cmake modules or GitHub - robotology/ycm: YCM (YCM CMake modules) is a collection of various useful CMake modules. but they seemed to suggest they provided a solution to this. They are old and unmaintained however.
I’m experiencing same issue. The generator expressions of all those linked libraries and conditions make it impossible to do that from reading some target property.
I think this is the way to go in CMake’s case but seems to be stalled at the time of writing: https://gitlab.kitware.com/cmake/cmake/-/issues/22621
Otherwise, I’ll probably have to collect these private libraries into a list variable over the configuration phase. Yes, quite annoying approach and feels like moving few steps back with all these imported and interface targets, but is probably the least error prone.
I’ve also tried parsing the CMakeFiles/<target_name>.dir/link.txt file but it would be a bit difficult to get all libraries based on the various linkers and combinations correctly manually.
Hello @Peter_Featherstone , ycm-cmake-modules
maintainer here.
Just to understand, why do you state that it is unmaintained?
However, more in topic, in ycm-cmake-modules
we do not provide any functionality to generate pkg-config’s .pc
files.
Ah sorry, I was talking about BCM. That’s definitely old and unmaintained.
Hi! I think the original post is fairly clear in asking specifically about using get_target_property
to generate a pkg-config file and running into the issue of the generator expressions not having been expanded at the time the file is generated.
My impression is that the original request implies that targets’ properties already implement some complex logic concerned with the includes, and flags, and dependencies, etc, and the author must wish to reuse that logic when generating the .pc
export. It is a valid use-case to use CMake to generate package info consumable by non-CMake projects. I’m afraid your references to the docopt example, and man pkg-config
, to find_package
may have pulled the conversation in a completely different direction and possibly created some… tension.
On the subject matter, I don’t see any file(GENERATE ...)
in cmake-pcfilegenerator/PcFileGenerator.cmake at main · antoniovazquezblanco/cmake-pcfilegenerator · GitHub (from CMake module to automatically generate pkg-config PC files from targets) but I do see a get_target_property
, I wonder how that works.