On Wed, Jan 14, 2015 at 16:20:52 +0000, Robert Goulet wrote:
> To be honest I haven't spent much time trying to learn 'imported'
> libraries with CMake. It was already difficult to deal with commands
> that don't support generator expressions versus those that does. It
> wasn't clear which commands we should not try to use because of that,
> and in the end we had to rewrite part of the CMakeLists.txt file
> because we wanted to use generator expressions and packages.
Yeah, documentation for where commands accept genexes should be more
comprehensive (generally, if it isn't mentioned, they aren't supported
but I'm sure there are gaps in there).
> Talking about that, what is the correct way to use generator
> expressions in a context of packages? find_library does not support
> generator expressions, so right now in our Find files we don't use it,
> we just set variables instead.
Since CMake doesn't support hybrid Debug/Release build trees outside of
XCode or Visual Studio, general support is pretty hard. Basically, I'd
say export your targets where possible and make imported targets instead
of using variables elsewhere. There should be properties you can set to
indicate whether the found library is release or debug. Skimming the
docs shows the IMPORTED_CONFIGURATIONS property.
> For example, consider the following external library setup:
>
> root/lib/vs2012/x86/debug/foo.lib
> root/lib/vs2012/x64/debug/foo.lib
> root/lib/vs2012/x86/release/foo.lib
> root/lib/vs2012/x64/release/foo.lib
> root/lib/ios/debug/foo.a
> root/lib/ios/release/foo.a
> root/lib/android/debug/foo.a
> root/lib/android/release/foo.a
> etc...
>
> How does one deal with such a setup, when all versions of the library
> use the same name, but in different paths, within a package context?
> It would have been nice if find_library supported generator
> expressions. But maybe I misunderstood how to properly deal with that?
If this were the case, you wouldn't be able to know where the file is
until generate time (generator expressions may not have a real semantic
meaning until run *after* CMakeLists.txt has been parsed). The thing to
do here is find a debug path and a release path and set them either on
an imported target properly or use the
"debug;${debug_path};optimized;${optimized_path}" thing (though I'm not
all that familiar with what goes on with that).
--Ben
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
