[Cmake] Re: library dependency information

[William A. Hoffman]

So, to summarize:

1. You will add an option that removes duplicates just like the -L options 
are currently removed.
2. For static builds you will use the libraries that have been linked to 
libraries to get all the
needed libraries for an exectuable:
So if you have:
libA -> libB
Then you have an executable foo.exe that has a TARGET_LINK_LIBRARY(foo A)
you will know to add the -lB in the right order.

If projects are building on Windows all libraries will have the list of 
libraries that they link against, so most
projects will have this information.

You will have to make a cache entry to store the information.   Something like:
A_LIBRARY_LINKS:INTERNAL:B

There is already some stuff like that going on in the cache, look at your 
cache to see.

Also, I like the idea of moving this into the generator parent class.   We 
could add a method there to collapse
the library path and library link options.  The code is duplicated in the 
two generators now.

-Bill



At 04:47 PM 1/17/2002 -0500, Amitha Perera wrote:

> > I don't see how this will help to compress the path.  You could add a
> > variable that stops the
> > library duplication that is done on unix, but other than that, I don't see
> > what you are going to
> > do that is different than what is being done.
>
>In the general case, you are right, it will do nothing. There are two
>additional pieces that can be used to do more:
>
>1. If the libraries are known to have a tree-like dependency
>    structure, and the libraries are known to be specified in the correct
>    order, you can remove duplicates:
>       -la -lb -la    =>  -lb -la
>
>2. If the CMakeLists.txt has full dependency information (that the
>    developers have explicitly added), then a lot of reduction can be
>    done.
>       ADD_LIBRARY( z )
>       ADD_LIBRARY( a )
>       ADD_LIBRARY( c )
>       TARGET_LINK_LIBRARIES( c a )
>       ADD_LIBRARY( b )
>       TARGET_LINK_LIBRARIES( b a )
>       TARGET_LINK_LIBRARIES( a z )
>       ADD_EXECUTABLE( e )
>       TARGET_LINK_LIBRARIES( e c b )
>    The link line for e can automatically be determined as
>       -lc -lb -la -lz   or  -lb -lc -la -lz
>
>Part 2 requires the explicit entry of dependencies, which takes effort
>and is probably not in place for many projects. However, I strongly
>believe it is not in place because no (Unix?) tools really have a
>place to use that information, or use it effectively. CMake is a tool
>that can really put that information to use. In particular, if this
>information is in place, then a parallel build dependency would go
>something like:
>           e <--- c  <--- a  <---- z
>              \-- b  <--/
>which is the most parallelism you can expect, and still be consistent
>with the serial build.
>
>Yes, I admit most projects may not use it, but I like to think that if
>it were available, and well documented, more people would adopt it.
>
>For vxl in particular, the CMakeListsLink.txt is a hack to document
>the immediate dependencies for each library, so that the full
>dependencies can be automatically generated. This would give a better
>way of doing that.
>
>Amitha.