Re: [CMake] behaviour change in MakefileGenerator3

[Alexander Neundorf]

> 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 had a look at cmLocalUnixMakefileGenerator3.cxx, WriteMakeRule(),

// Split dependencies into multiple rule lines.  This allows for
// very long dependency lists even on older make implementations.
for(std::vector<std::string>::const_iterator dep = depends.begin();
    dep != depends.end(); ++dep)
{
    replace = *dep;

At this point I entered some debug output and tested the various functions
with the following results:
replace == "config.h"
GetFilenamePath(replace) == ""
Convert(GetFilenamePath(replace),FULL,MAKEFILE)==/home/alex/src/cmake-acc/
cmSystemTools::CollapseFullPath(replace)=="/home/alex/src/cmake-acc/config.h
m_Makefile->GetCurrentDirectory() ==/home/alex/src/cmake-acc/foo/ 

GetCurrentDirectory() returns what I expected, Convert() and
CollapseFullPath() return IMO the wrong (CMAKE_SOURCE_DIR) directory.

I didn't get further until now. Is there a function like bool
cmSystemTools::IsRelativePath(const char* dir) ? What's the recommended way
to convert a relative path to a absolute path ? Simply dir + file ?

Bye
Alex

-- 
5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail
+++ GMX - die erste Adresse für Mail, Message, More +++