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

[Raymond Wan]

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