[cmake-developers] cmake --help-policy CMP0057 MAIN_DEPENDENCY

[Nils Gladitz]

On 05/12/2015 07:23 AM, James Bigler wrote:
> OK, thanks.
>
> I still think that if there is a difference in behavior for Makefile
> generators between MAIN_DEPENDENCY and DEPENDENCY there is a bug in
> CMake.  Perhaps there needs to be bug filed for that.  Here's the
> documentation:
>
> In makefile terms this creates a new target in the following form::
>
>   OUTPUT: MAIN_DEPENDENCY DEPENDS
>           COMMAND
>
> For a makefile, there shouldn't be a difference between the dependency
> coming in on MAIN_DEPENDENCY or DEPENDENCY.  CMake is doing something
> else with that property.

I would prefer that too but the add_custom_command() implementation 
which handles MAIN_DEPENDENCY and DEPENDENCY and attaches commands to 
source files is common to all generators.

Treating MAIN_DEPENDENCY and DEPENDENCY the same for Makefiles in this 
case would break existing projects (when using the Makefile generators) 
when they list the source file named by MAIN_DEPENDENCY but not the 
source file named by OUTPUT since then the custom command would not get 
emitted at all.


> 2. I'm curious why this causes a problem.  It seems to me that dummy.cpp
> should be present by the time the add_custom_command is even run,

Yes, it is.

> so why would it care whether it was created by CMake or anything else?

That isn't the issue.

The test case failure depends on the presence of the custom command but 
the custom command is not involved in creation of dummy.cpp; it only 
uses it as input.

Due to MAIN_DEPENDENCY the custom command is attached to dummy.cpp.

I think the issue is due to cmake trying to attach the command used to 
compile dummy.cpp itself as a custom command as well. [1]

Nils

[1] 
http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmLocalGenerator.cxx;h=88c88cd133a753fc319a785e116fdb8e6d5fd94a;hb=HEAD#l580