[Cmake] Dependency handling problems with 1.8

[Ken Martin]

Some more information on this issue.  This is a UNIX makefile issue =
where
the subdirectories are processed in the order you specify. So make (not
cmake) will build a first then a_gui and then b. If you then modify a =
file
in b and run make from the top; make will not rebuild a_gui because =
a_gui
depends on b and b is not modified (yet). Once make goes into b (where =
it
knows about the dependency of b on some_b_sourcefile then it will =
rebuild b
but a_gui is still built against an old version of b.  Did that make =
sense?
There are a few ways to get around this. The easiest is to make sure =
your
directories are in the right order. I don't know if this will help but =
you
might be able to do=20

(toplevel CMakeLists.txt)
    SUBDIRS( a )
    SUBDIRS( b )
    SUBDIRS( a/a_gui )

That way "a" will be processed first, then "b", then a/gui which depends =
on
both of them. The other way is to include the full dependency tree of b =
into
the Makefile for a_gui. This makes for huge Makefiles for large projects =
and
more frequent rebuilding of Makefile (because they now depend on many =
more
header files) For example the vtk executable's Makefile would have to
include the dependency tree for every library in vtk.=20

Now the first time you build, CMake is smart enough to realize that if =
"b"
does not exist it must jump over into the b directory and build b first
before it can build a_gui. The problem is that once "b" exists then Make
doesn't have enough information to decide if it needs to jump over into =
b.=20

- Ken


> -----Original Message-----
> From: cmake-admin at www . cmake . org [mailto:cmake-admin at www . cmake . org] On
> Behalf Of Andy Cedilnik
> Sent: Wednesday, October 01, 2003 2:22 PM
> To: Amitha Perera
> Cc: cmake at www . cmake . org
> Subject: Re: [Cmake] Dependency handling problems with 1.8
>=20
> Hi Amitha,
>=20
> CMake 1.6 had this problem, it just did not tell you about it.
>=20
> The problem is that CMake evaluates directories in a specific order. =
All
> directories are evaluated child first. So, in your case, a_gui is
> evaluated first, then a and then b.
>=20
> Now, this does not mean your project will not work. It will, and
> dependency handling will work to some extent. The problem is that if =
you
> modify file in b, it will not rebuild a_gui.
>=20
> Some of this will be fixed by SUBDIRS ordering.
>=20
> 			Andy
>=20
>=20
> On Wed, 2003-10-01 at 14:00, Amitha Perera wrote:
> > CMake 1.8 gives errors on dependency handling in what (we think) are
> > reasonable situations.
> >
> > Consider:
> >
> > (toplevel CMakeLists.txt)
> >    SUBDIRS( a )
> >    SUBDIRS( b )
> >
> > (a/CMakeLists.txt)
> >    ADD_LIBRARY( a ... )
> >    SUBDIRS( gui )
> >
> > (a/gui/CMakeLists.txt)
> >    ADD_LIBRARY( a_gui ... )
> >    TARGET_LINK_LIBRARIES( a_gui a b )
> >
> > (b/CMakeLists.txt)
> >    ADD_LIBRARY( b ... )
> >    TARGET_LINK_LIBRARIES( b a )
> >
> > Here, the dependency tree is simple, well-defined, and acyclic:
> >    liba <-- libb <-- liba_gui
> >
> > However, CMake issues an error that "b" is seen in a TARGET_LINK
> > before it is seen in an ADD_LIBRARY. Further, it issues a dire =
warning
> > that "this may break the dependency handling".
> >
> > CMake 1.6 did not have this problem. Does someone know why this
> > warning was introduced, and how we can go about making it go away?
>=20
>=20
> _______________________________________________
> Cmake mailing list
> Cmake at www . cmake . org
> http://www . cmake . org/mailman/listinfo/cmake