cmake issue: generated files in subdirs

Aaron J. Seigo aseigo at
Fri Mar 24 01:28:19 GMT 2006

On Thursday 23 March 2006 15:49, Alexander Neundorf wrote:
> Something like
> macro(make_build_tree_location result infile outfileName)
>    get_filename_component(absPathToFile ${infile} ABSOLUTE)
>    get_filename_component(absPath ${absPathToFile} PATH)
>    file(RELATIVE_PATH relPath ${CMAKE_CURRENT_SOURCE_DIR} ${absPath} )
>    set(${result} ${CMAKE_CURRENT_BINARY_DIR}/${relPath}/${outfileName} )
> endmacro(make_build_tree_location result file )
> in an own file kdelibs/cmake/modules/MakeBuildTreeLocation.cmake I'd say,
> so that it can then be used:
> make_build_tree_location(outFile file.ui file.h)

hmm. i'm not sure what's less ugly: changing this app in svn so i don't have 
to use this, or using it. =)

> > > At least the example you give above cannot work for KDE, independently
> > > from the buildsystem (see explanation above).
> > >
> > > If we reintroduce convenience libs it will work, otherwise it can't.
> >
> > even with -I. and requiring that files outside of '.' must refer to paths
> > properly in #includes (e.g. #include "modules/mod1/module.h")? that at
> > least is a more common requirement IME. or is this because cmake doesn't
> > actually run gcc from the directory the file is in, but from the base
> > directory handing gcc a relative path to the file to be compiled?
> cmake runs gcc from the builddir, so with out-of-source builds, the
> includes are only found via the include path.

sure, but in the builddir, it doesn't descend into the directory hierarchy to 
do builds, is what i'm saying... so having -I. wouldn't fix anything .......

Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <>

More information about the kde-core-devel mailing list