[CMake] Problems with LIBRARY_OUTPUT_PATH

Brad King brad.king at kitware.com
Fri Apr 15 14:03:42 EDT 2005


Lars Pechan wrote:
> I have a very similar problem to this. Basically, I use a long chain of 
> custom commands to generate a resource-file which is subsequently used 
> for building a shared lib. The generated res-file has the GENERATED 
> source file property set to true (as do some of the others in the chain).
> 
> The lib line is akin to this:
> 
> ADD_LIBRARY(LibA $GenDir}/${GenResFile} dllDummy.c)
> 
> This builds nicely BUT the problem is that it always builds.

If the whole chain reruns then something near the beginning of it must 
be considered out of date or missing.  Check your dependency chain to 
see if you can find it.

> Interestingly, the output of nmake when building the lib ends with:
> 
> Linking C shared library ..\..\..\..\..\libA.dll
> LINK: LNK6004: ..\..\..\..\..\libA.dll not found or not built by the 
> last incremental link; performing full link
> 
> This message is displayed regardless of whether ..\..\..\..\..\libA.dll 
> exists.

This may be because the library flags used are not configured for 
incremental linking so the linker always performs a full link even if 
the library is already present.

It looks like you are using a version of CMake from CVS.  One of the new 
features of the makefile generator is that build rules depend on 
themselves so that if the rule changes (like adding a -D option) then 
the output of the rule is considered out of date and the rule reruns. 
You may have something configured to make the rule file change alot 
which would cause things to rebuild.  To disable this feature add this 
line to the list file code:

SET(CMAKE_SKIP_RULE_DEPENDENCY 1)

If that fixes the problem then I'm definately interested in a minimal 
example that reproduces it to figure out why the rule files are changing.

-Brad


More information about the CMake mailing list