[CMake] Feature request: generic (config-like) selector on target_link_libraries

[Alexandre Feblot]

> > Specifying the lib4 dependency in the exe? But what about
dependencies
> > order in the link line? In my example, lib4-A or lib4-B must appear
> > after lib3, if I want lib4 symbols required by lib3 to be added. In
your
> > solution, lib4 might as well be added by cmake just after lib1 and
> > before lib3, which will result in a link failure.
> 
> IF( SOMETHING )
>   SET (LIB4_VER "lib4a")
> ELSE( SOMETHING )
>   SET (LIB4_VER "lib4b")
> ENDIF( SOMETHING )
> 
> ADD_EXECUTABLE(exe1 ${exe1_SRCS})
> TARGET_LINK_LIBRARIES(exe1  lib1 lib2 lib3 ${LIB4_VER} lib5)

By doing so, you get rid of the cmake automatic dependency management,
and you build your link line by hand. This is not really an option with
360 libraries used by 60 different executables, when dependencies
between libraries are added or removed every week (by the way, this is
more or less the way my current system works, and this becomes a
nightmare).

> > More over, the executable is even not supposed to know that it
depends
> > on lib4. It just knows it depends on lib1, which knows it depends on
> > lib3, which knows it depends on lib4. (I gave a simple
> 
> ADD_LIBRARY(lib1a ...)
> TARGET_LINK_LIBRARIES(lib1a  lib2a)
> 
> ADD_LIBRARY(lib2a ...)
> TARGET_LINK_LIBRARIES(lib2a  lib3a)
> 
> ADD_LIBRARY(lib3a ...)
> TARGET_LINK_LIBRARIES(lib3a  lib4a)
> 
> ADD_LIBRARY(lib4a ...)
> TARGET_LINK_LIBRARIES(lib4a  lib5)
> 
> # Etc
> 
> IF( SOMETHING )
>   SET (LIB1_VER "lib1a")
> ELSE( SOMETHING )
>   SET (LIB1_VER "lib1b")
> ENDIF( SOMETHING )
> 
> ADD_EXECUTABLE(exe1 ${exe1_SRCS})
> TARGET_LINK_LIBRARIES(exe1  ${LIB1_VER})

Yes, I already thought about this one too, but duplicating and
rebuilding about 200 libs (about 9 millions of code lines) when I
already have build duration issues is not really where I'd like to go.
Cmake is supposed to help me do better than my current system.


> > example, but the
> > real project is a large one with many dependencies,
> > including circular
> 
> CMake is not a chicken-and-egg solution. It is a build system.

Ok, let's forget about my 'circular' issue, this is an other topic.

 
> > ones, and we don't want / can't easily know all
> > libX-A/B that must be added to every executable)
> 
> In one CMake build tree you can have only one target LIB1, LIB2 and
LIB3.
> In your example LIB3 depends on LIB4a and at the same time - on LIB4b
which
> is not possible. Bool can be either TRUE or FALSE, but not both.
> 
> In your example (below)
> exe1-A -> lib1 -> lib3 -> lib4-A -> lib5 -> lib7
> exe1-B -> lib1 -> lib3 -> lib4-B -> lib6 -> lib8
> you know that you need A or B only at link time. This means that you
need
> to specify ALL required dependencies at link time.
> 
> If you knew, what you need at LIB3 stage, then you would have done it
already.

The current TARGET_LINK_LIBRARIES already offers a way to add different
dependencies based on a configuration which is defined later (debug or
optimized). But this mechanism is only used in this special purpose.
My need is that at link time, I must choose which implementation of a
single interface I want to use, and both implementations have different
dependencies. This looks rather similar, doesn'it?
That's why I was proposing a similar answer too; this is just a more
general way to add such a configurable dependency, ans it gracefully
solves the issue.


> I see the following solutions:
> 
> 1) LIB1A, LIB2A, etc
> 2) For each executable generate separate BUILD directory
>    where there will be only one lib1->lib2->lib3->lib4->lib5 chain.
> 3) Specify what you want at link time.

None of which is really an efficient solution, either for maintenance or
cpu/disk resources, do you agree with me?

> 
> > binaries: for some
> > of them, lib3 must depend on lib4-A, and for some others,
> > the same lib3 must then depend on lib4-B.
> 
> It is not possible.

It is indeed not possible in current cmake state. That's why I asked
about this new feature. A link time variation is a usual need not yet
truly handled by cmake.
Did I manage to convince you about the need and the current lack of true
solution?

For the record, I my case, the need is to create 2 flavours of
executables, one working with a database, the other with webservices.

Alexandre

This email was sent to you by Thomson Reuters, the global news and information company.
Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thomson Reuters.