Re: [CMake] behaviour change with SET SOURCE FILES PROPERTIES( OBJECT DEPENDS)

[Alexander Neundorf]

> Von: Brad King <brad.king at kitware.com> 
>  
> Alexander Neundorf wrote: 
> > Hi, 
> >  
> > please try the attached test case. 
> > The problem here is (actually the same as the previous problems with 
> > CONFIGURE_FILE and ADD_CUSTOM_COMMAND) that the working directory of 
> > make with the new makefile generator has changed and so all relative 
> > paths work differently. 
> > This is also the case for 
> > in src/foo/: 
> >  
> > SET_SOURCE_FILES_PROPERTIES(main.c PROPERTIES OBJECT_DEPENDS foo.h) 
> >  
> > This generates the rule 
> >  
> > foo/main.c : foo.h 
> >  
> > which should better be: 
> >  
> > foo/main.c: foo/foo.h 
> >  
> > I can work around it by prepending ${CMAKE_CURRENT_SOURCE_DIR}, but  
> > it worked with previous versions of the makefile generator. 
>  
> I need to point out here that even with CMake 2.0 none of the old  
> relative path behavior would work with an out-of-source build.  That  
> has always required full paths for these commands to work properly.  I 
 
Yes, I know this. But for the simple case (in-source-build) relative 
filenames were interpreted as expected, relative to 
CMAKE_CURRENT_SOURCE_DIR. This has changed with the new makefile 
generator, since make now always works from CMAKE_SOURCE_DIR (or 
CMAKE_BINARY_DIR).  
 
I think for basic commands cmake should be able to handle this (e.g. it 
works if you just list the filenames in ADD_EXECUTABLE() without 
prepending CMAKE_CURRENT_SOURCE_DIR). 
SET_SOURCE_FILES_PROPERTIES OTOH is IMO quite advanced, so that there 
it's not such a big problem if it doesn't work (but it would be nice if 
it would) 
 
Bye 
Alex 
 

-- 
Weitersagen: GMX DSL-Flatrates mit Tempo-Garantie!
Ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl