Ok, great. Can you tell me a bit more about "implicit compile flags [...] for imported tagets"?
On the library I'm currently working on, with Visual Studio, I have to declare some compile definition in order to get the proper "__declspec(dllimport)" or "__declspec(dllexport)" defined (or not defined when compiling/using a static version of this library). Does "implicit compile flags" means that those compile definition could be automatically declared by the imported target? 2013/10/30 Matthew Woehlke <[email protected]> > On 2013-10-30 13:56, Cyrille Faucheux wrote: > >> I'm trying to learn how to properly import/export librairies with CMake. >> >> I think I've read somewhere that the proper way to export libraries is >> through the module mode (as described in [1]), but: >> a) I can't find back where I've read that, >> b) Lots of libraries are still using the module mode (Find*.cmake). >> >> Can you confirm me which mode I should choose? >> > > It's definitely preferred these days to work with exported/imported > targets where possible. Unlike find modules, imported targets let you link > to target names in consuming projects. Also, now that target usage > requirements have arrived, you can have implicit compile flags, include > directories, and interface link libraries for imported targets. All of this > makes it much easier to use external libraries and lessens the distinction > between an imported and local target. > > Additionally, this happens in one place. Find modules tend to end up > copied about to different projects until/unless they wind up in CMake > proper, and even then can linger on, resulting in multiple versions in > varying states of bitrot. They can even be written multiple times by > different people in unrelated projects. By providing a package config file > (even one that just sets find module style variables) you prevent this > proliferation and duplication of work. > > The flip side (and why you have a lot of find modules still) is that the > onus to provide a package config file is on the upstream. This means that > upstream must either build with CMake in the first place, and have the > necessary logic in the CMake build instructions to generate a package > config file (ideally with exported targets), or else be friendly enough to > CMake to generate 'by hand' such a file despite using some other build > system. It should go without saying that, especially in the latter case, > politics can become involved here. > > -- > Matthew > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/**CMake_FAQ<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<http://cmake.org/cmake/help/support.html> > CMake Consulting: > http://cmake.org/cmake/help/**consulting.html<http://cmake.org/cmake/help/consulting.html> > CMake Training Courses: > http://cmake.org/cmake/help/**training.html<http://cmake.org/cmake/help/training.html> > > Visit other Kitware open-source projects at http://www.kitware.com/** > opensource/opensource.html<http://www.kitware.com/opensource/opensource.html> > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/**listinfo/cmake<http://www.cmake.org/mailman/listinfo/cmake> >
-- 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://www.cmake.org/mailman/listinfo/cmake
