Re: [PATCH] make ADD CUSTOM COMMAND() work with relative paths was: Re: [CMake] behaviour change in MakefileGenerator3

Alexander Neundorf a.neundorf-work at gmx.net
Sat Jul 9 04:15:32 EDT 2005


> Von: "Alexander Neundorf" <a.neundorf-work at gmx.net>
> 
> > Von: "Alexander Neundorf" <a.neundorf-work at gmx.net>
> > 
> > Hi,
> > 
> > the attached patch makes ADD_CUSTOM_COMMAND() work again with the
> makefile
> > generator v3 if the source or depend files are given with relative (or
> no)
> > paths. See the rest of this thread for details and a testcase.
> > It's done similar to the change in cmConfigureCommand.cxx
> > 
> > Bye
> > Alex
> 
> Somehow this still doesn't always work.
> I see that e.g. date_object.lut.h is expanded to
> /home/alex/src/kde3/kdelibs/kjs/date_object.lut.h in
> cmAddCustomCommand.cxx
> and appended so to the depends vector.
> When iterating through the events vector late in
> cmLocalUnixMakefileGenerator3::WriteMakeRule() it has completely lost its
> path :-/
> 
> in kdelibs/kjs/date_object.cpp there is
> #include "date_object.lut.h"
> 
> Might it be possible that the C dependency scanner finds this
> date_object.h 
> and prefers this over the one with the full path somehow ?
> 
> Bye
> Alex

Ok, this wasn't completely correct.
The patch I sent fixes the problem I have, testcase is attached.
The problem I'm seeing here is with SET_SOURCE_FILE_PROPERTIES, see my other
mail.

Bye
Alex

-- 
5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail
+++ GMX - die erste Adresse für Mail, Message, More +++
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cmake-acc-2.tar.gz
Type: application/gzip
Size: 509 bytes
Desc: not available
Url : http://public.kitware.com/pipermail/cmake/attachments/20050709/0ed355f4/cmake-acc-2.tar.bin


More information about the CMake mailing list