[CMake] Executable using a library (.a or .so)

[houssen]

Ray,

What you say sounds totally logical to me ! So I'll stick to option 1 
as you described it.

Thanks for explanations, this is helpfull.

Franck

Le 2015-11-14 16:37, Raymond Wan a écrit :
> Hi Franck,
>
>
> On Sat, Nov 14, 2015 at 11:05 PM, houssen <houssen at ipgp.fr> 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