cmake issue: generated files in subdirs

[Aaron J. Seigo]

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 (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060323/e7e027a2/attachment.sig>