![]() ![]() Do the same for any variables that need to be surfaced. Call find_package() in each, and recursively parse the targets via the manual examination of all target properties, heuristically determining which properties refer to targets. The only solution I’ve found (possibly the only solution that exists without namespacing or building the library from source) is the following ridiculousness: run two separate CMake instances in a subprocess via execute_process(). ![]() And right now the targets have the same name across debug/release and don’t annotate their build configuration in the way you describe. Note that I’m trying to work within the confines of pre-built libraries that are externally provided, and make it backwards compatible, so given that constraint I wouldn’t be able to change how things are installed/exported. I’ve seen that namespacing discussion, and I think it would be the “right” solution here, probably the only right solution (unfortunately it doesn’t seem like it’s going to happen in the near term). Changing the original library to support multi-config would be quite complicated and would not support backwards compatability. If you have any other ideas for approaching this I’d appreciate it. So the second find_package() call will silently use the targets defined from the first call for all of the internal libraries.īasically all I need is the ability to call find_package() twice and distinguish targets with the same name. ![]() You can get around this with the NAMES option to alias the packages, but each config doesn’t just define itself – it defines a recursive web of targets, and none of these targets are distinguished by configuration. If I run find_package() twice and try to specify the paths for each version, CMake will ignore the second path because it’s silently cached the location from the first call. They have the same name, which is the first issue. CMake is making it pretty tricky though.īoth versions of the pre-built libraries include a Fiind.cmake file. The included Find.cmake do not seem to support multi-configuration setups well, but I know this should still be possible in theory. And I would just like to hook them up in a Visual Studio multi-configuration setup. I’ve got some large, pre-built libraries that are released separately for the Debug and Release versions. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |