Hi Franck,
On Sat, Nov 14, 2015 at 11:05 PM, houssen <[email protected]> wrote: > I tested your proposal (need to add target_include_directories to find > headers) : > # in MyLib/CmakeLists.txt > add_library( MyLib <STATIC/SHARED; default STATIC> libsource1.c > libsource2.cpp ) > # in MyExe/CmakeLists.txt > add_exectubable( MyExe exesource1.c ) > target_include_directories(myExe PUBLIC ../myLib/hdr) > target_link_libraries( MyExe MyLib ) > > This is working, so OK I can use that. But what if the user wants to build > myLib as a .a or a .so ? It seems it not possible to change that from ccmake > (I've just checked). It should be possible when using Find*.cmake, no ? I'm not a CMake expert, but I think you will issue two add_library ()'s, one for the shared and one for static. I don't think I can say it any better than this: http://stackoverflow.com/questions/2152077/is-it-possible-to-get-cmake-to-build-both-a-static-and-shared-version-of-the-sam (even though it's 5 years old, I think it's still relevant). If we're talking about the source code associated with the CMakeLists.txt you're processing, then presumably you already know about libsource1.c, exesource1.c, etc. so you don't need to do Find them. However, if it's a set of files, libraries, etc. that has been installed independently of the source code in question (i.e., Boost or something you wrote that you've required the user to have done a "make install" beforehand), then you would issue a Find*.cmake (or write one if it's your own libraries). I'm not too sure about this, but I think that's the distinction between when to use Find*.cmake and when you don't need to. > ... But, precisely, when typing target_include_directory you need to know > the path to headers directory (+ path to libraries directory ?): this is why > I felt like "Okay, I need to write a FindMyLib.cmake to handle this". My > understanding is that a (internal or external) library is a library, so, it > should be managed with a FindMyLib.cmake. Am I correct ? (I try to > understand the "CMake way" to do thing - I am more an autotools user, so, I > just try to understand CMake) In my source code, I might have some module A rely on a module B. However, both are within the same source tree. So, I can do Include_Directories () to add paths to header files or Add_Subdirectory () to add a subdirectory to the build. As it's all within the same source tree, I can find them using relative path names. However, if it's a .h or .hpp header file that was compiled and installed separately, then I would need to use ExternalSource () to acquire and compile it *or* use Find*.cmake to go to system paths to look for it. Incidentally, I've been looking into this the past week and I don't know if I got it right. But to summarize, this is what I think: 1) Include_Directories and Add_Subdirectory if the header files / modules are within the same source tree. 2) ExternalSource if this software is not part of the source tree and needs to be acquired *during* the build/compilation process. 3) use Find*.cmake if this software was acquired and built *before* the current build/compilation process. If you use Boost, then you would use FindBoost.cmake if you want the user to have installed Boost separately beforehand. You would use ExternalSource if you want Boost to be downloaded and installed in the same CMake binary tree as you're currently on. Not too sure...hopefully someone can correct me! Ray -- 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
