cmake issue: generated files in subdirs

[Alexander Neundorf]

On Thursday 23 March 2006 22:06, you wrote:
> On Thursday 23 March 2006 12:01, Alexander Neundorf wrote:
> > Are you building in-source or out-of-source ?
>
> out of source.
>
> > Which problem does this cause for you ?
>
> specifically, in porting i cam across a file includes the generated .h file
> which is in a subdir.. so the #include is:
>
> #include <dir/generatedfile.h>

Ok, this is indeed a problem.

> but generatedfile.h is in the top level dir. it just means more porting
> work and was a bit surprising to see generated files not ending up in the
> buildtree where they were in the sourcetree.

Well, it would be possible to generate the file in 
${CMAKE_CURRENT_SOURCE_DIR}/subdir/generatedfile.h . Something like

get_filename_component(absPathToFile file.ui ABSOLUTE)
get_filename_component(absPath ${absPathToFile} PATH)
file(RELATIVE_PATH relPath ${CMAKE_CURRENT_SOURCE_DIR} ${absPath} )
set(outputFile ${CMAKE_CURRENT_BINARY_DIR}/${relPath}/file.h )

> > Now all source files are just compiled at once for one target. So if
> > you have in different subdirs files with the same name, the generated moc
> > files will have the same name. Even if they would be generated in
> > different directories (which they are not currently), this wouldn't help
> > anything. In order to find them, the path to them would have to be part
> > of the include path. Which would mean the path to both files with the
> > same name would be in the include path, and that for both files. Which
> > would have the effect that both times when e.g. foo.moc gets included the
> > same foo.moc would be included.
>
> that's nice about moc and all, but we're talking about ui files here.
>
> in the case of moc files, -I. being before all others should suffice (the
> moc file being in the local dir). in the case of ui files, they are for
> intents and purposes just other c++ code. ditto for kconfigxt generated
> code, etc...
>
> the whole point of subdirs is to help organize and namespace files. i've
> worked on a few projects in the past where it was common to do:
>
> modules/mod1/module.h
> modules/mod2/module.h
>
> and no, those weren't plugins ... it's a little odd to not be able to do
> that just because the source are autogenerated. on larger projects this
> will become more of an issue as file name collisions increase.
>
> and while a project can certainly modify how it does things, it's a bit odd
> to modify something like that due to the -build system-. or is that the
> point, to remind the world that all build systems suck?

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.

Bye
Alex
-- 
Work: alexander.neundorf AT jenoptik.com - http://www.jenoptik-los.de
Home: neundorf AT kde.org                - http://www.kde.org
      alex AT neundorf.net               - http://www.neundorf.net