[CMake] XCODE_DEPEND_HELPER dependency issues

Nicolas Tisserand nicolas.tisserand at gmail.com
Fri Dec 21 07:31:59 EST 2007


Hi,

I'm working on a C++ project that's been happily using CMake as a
cross-platform (mac/pc/linux) build tool for a year now.

We're using CMake 2.4.6 on all platforms.

Recently, some changes in our build system lead to the following
dependency graph:

LIB1 <- EXE1 <- LIB2 <- EXE2
  ^                                    |
   `-----------------------------------'

(LIB* are static libraries, and EXE* executables)

EXE1 is a tool that generates input source files for LIB2, hence the
extra-dependency.

Everything works nice and smooth with the Linux / Make, MacOS X / Make
and WIN32 / VC80 generators.

Trouble is, on the mac, the XCODE_DEPEND_HELPER (XDH) is added to all
final (executable, dynamic libraries and modules) targets by the XCode
generator:

  .---------------------------------------
  v                                        \
LIB1 <-------.                          |
              EXE1 <- LIB2  <- EXE2
XDH <-------'                           |
  ^---------------- -----------------------'

When EXE2 (or ALL_BUILD) is the active target and LIB2 needs a
rebuild, the following happens:

* The XCODE_DEPEND_HELPER make command is run, doing nothing.
* EXE1 is left alone
* LIB2 gets correctly rebuilt
* EXE2 does not get relinked because when XCODE_DEPEND_HELPER was run,
EXE2 was still up-to-date with LIB2 :-(

This is very annoying.

Here's the only sort-of workaround I could come up with:

* remove the EXE1 <- LIB2 dependency, so that EXE2 gets correctly
relinked when the active target is EXE2
* exclude EXE1 from the build (using EXCLUDE_FROM_ALL), so that EXE2
gets correctly relinked when the active target is ALL_BUILD

But this forces XCode users to rebuild EXE1 manually.


Finally, here are my questions:

Is there a nicer solution to my problem?
Is this a known bug?
Are there any plans for fixing it?
Would 2.4.7 solve my problems? (I checked the ChangeLogs but did not
see any mention of it)

Sorry for the bad ascii-art :-)
-- 
Nicolas


More information about the CMake mailing list