[cmake-developers] Exporting an imported target not supported?
Lassi Niemistö
lassi.niemisto at wapice.com
Tue Mar 12 09:55:46 EDT 2019
> The file `cmake_test_system_lassi/tree1/Tree1Config.cmake` should have code to re-create the extlib imported target
> with whatever usage requirements it had for building tree1. See the patch below.
> In combination with removing all the `extlib_interface` code, the `test.sh` script passes.
> Generally imported targets are not manually created by project code.
> Instead they come from `find_package(MyDependency)`. Tree1Config should repeat `find_package(MyDependency)` for
> public-facing dependencies. If you don't want to create a complete find module for extlib, you can create a normal
> module that gets `include()`d from both places.
I see. In my case extlib is really an external lib which does not provide any cmake helpers (finder modules / configs) so I need to write them myself.
I wish to totally hide the need of extlib from tree2 perspective and not call its finders there. Actually, I would like to not care about it even at the point of exporting mylib, as extlib is a tiny tiny sub-sub-dependency of mylib. I would like to do this via modern target base cmake approach together with export mechanisms. Needing to also provide parts of my tree1 cmake code for tree2 kind of breaks this abstraction. Just being able to export all the imported targets as well would be cool, but seems that the workaround I did is actually pretty close.
Posted an iterated version https://gitlab.com/lassi.niemisto/cmake_import_case/commit/9f6a26284835ab272dcc8acd5bfde144e73fafe8
Thanks for all the rubberducking! I think this solution suffices. Just one more question: is there a technical reason why it would not be a good idea to allow exporting the imported targets with all their properties?
-Lassi
More information about the cmake-developers
mailing list