[CMake] behaviour change in MakefileGenerator3

[Brad King]

Alexander Neundorf wrote:
>>Von: "Alexander Neundorf" <a.neundorf-work at gmx.net>
>>
>>>Von: Brad King <brad.king at kitware.com> 
>>>An: Alexander Neundorf <a.neundorf-work at gmx.net> 
>>
>>...  
>>
>>>>If I enter make in src/firmware/app/test/, with the new Makefile  
>>>>generator ecos/ecos.ecc is searched relative to src/, i.e.  
>>>>src/ecos/ecos.ecc .  With the older makefile generator it was 
>>
>>searched  
>>
>>>>relative to the current directory, i.e.  
>>>>src/firmware/app/test/ecos/ecos.ecc .  
>>>>  
>>>>I guess the reason are the new flat makefiles. Is this change  
>>>>intentional ? (I can work around it by adding  
>>>>${CMAKE_CURRENT_SOURCE_DIR} )  
>>>
>>> 
>>>The problem is that the current working directory of the make process  
>>>is now different.  The new generator adds commands to set the working  
>>>directory properly before invoking the custom command.  You can find  
>>>the rule in TARGET.dir/target.ld.build.make where TARGET is the name of 
>>>the target in which the custom command is used.  The cd command should 
>>>be there. 
>>> 
>>>I think your problem is that the new shell gets started in the wrong  
>>>directory.  UNIX-style makes run each command (\n\t-separated) in its  
>>>own new shell.  CMake accounts for this by adding "cd proper/dir && "  
>>>before each line.  Somehow make is using the wrong current directory  
>>>when it starts the "sh" command.  If you inspect the make rule you may  
>>>be able to tell why. 
>>
>> 
>>Not sure. 
>>I attached a simple testcase. 
>>If you look in cmake-acc/foo/CMakeLists.txt, you will see an 
>>ADD_CUSTOM_COMMAND() which depends on config.h . It doesn't find 
>>cmake-acc/foo/config.h, but instead uses cmake-acc/config.h (which is not 
>>what I would expect). Just remove the ${CMAKE_CURRENT_XXX_DIR}s in 
>>cmake-acc/foo/CMakeLists.txt too see what I mean. (cmake cvs june 29th, 
>>unix makefile generator). 
>> 
>>Bye 
>>Alex
> 
> 
> If I have in foo/CMakeLists.txt the following command:
> 
> ADD_CUSTOM_COMMAND(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/config.c
> COMMAND cp
> ARGS config.c.in config.c
> DEPENDS config.h)
> 
> the following rule is produced:
> 
> foo/config.c: config.h
> foo/config.c: foo/hello.dir/config.c.build.make
>         @echo "Generating config.c"
>         cd /usr/home/alex/src/cmake-acc/foo && cp config.c.in config.c
> 
> IMO obviously foo/config.c should depend on "foo/config.h" instead of only
> "config.h". This is how it was up to UnixMakefileGenerator2.

I just tried this and I think it has been fixed.  I get a dependency on 
foo/config.h.

-Brad