Boost logo

Boost-Build :

Subject: Re: [Boost-build] Files with same name in different directories
From: Juergen Hunold (juergen.hunold_at_[hidden])
Date: 2008-11-14 08:47:54

Hi Volodya !

On Thursday 13 November 2008 09:33:43 Vladimir Prus wrote:
> I've just checked in this patch:
> What I've checked in is a minor revision of that patch.
> Jürgen, can you check that those "minor" revision did not broke anything
> for you?

So, just returned from Vienna and found the patch applied :-)). Thanks !
Everything works as expected.

> Also, in
> you say:
> 3) The usage of determine-target-name in other modules (I tried qt4.jam)
> in its current state is not a good idea because the include-path to the
> generated file is not adjusted. This should somehow be documented. I
> think that having more than one "a.ui" file in one Jamfile is asking
> for trouble anyhow :-))
> Can you explain what you mean.

Okay, I'll try to explain what is going on.

The ui files contain the a XML-document descibing some GUI-elements. In Qt4,
this XML-description is converted to a c++ header file by running the "uic",
the User Interface Compiler". So you get "a.ui" -> "a.h". See

for details. The user can then use the generated code by subclassing from the
generated class or by embedding this class in a member variable or "pimpl".
Sooner or later (pimpl usage) you have to add "#include "a.h"" to your code.
And this is the point where it gets interesting...

qmake, the build system generator used by Qt, does not support files with the
same name in different subdirectories and creates a "flattened" directory for
generated object and other intermediate files. Just like BB did before the
patch. The generated files are put in a separate directory which is added to
the compiler includes. The user can simple do an "#include "a.h" and
everything works out of the box.
Boost.Build Qt4 support aims to be compatible with qmake output. So we put all
generated headers in one directory and add this to the compiler includes.
Now let some user add "dir1/a.ui" in his Jamfile. Right now, we ignore the
"dir1" component and put a.h in the some place as ""dir2/b.ui" -> b.h". The
user can write #include "a.h" and #include "a.b" and everything works with
bjam and qmake (and CMake, btw. .;-))).
If we adjusted the output path by changing "a.h" -> "dir/a.h" with a call of
determine-target-name, we would have to adjust the include directories to
include the "dir1" component, too. Else the user would have to add #include
"dir1/a.h" which would break compilation with qmake and CMake.
While this would allow to have "dir1/a.h" and "dir2/a.h", this would lead to
severe complications if BB is not the only build system around (my situation

I hope this clears things up a bit.

> At the time the patch was posted, Jurko made some comments, the most
> important being:
> * Could it be made to work the same even when source paths are given
> as absolute names but still point to inside the source-location tree?
> Currently it treats such paths as it did before - just placing them in
> the top-level build folder.
> * Related to the previous comment, if you have source-location /A/B/C
> and specify a source file as ../C/X/x.cpp, could it correctly create the
> obj target in X/x.obj instead of just x.obj?
> These points probably need addressing, but I want the dust from the base
> patch to settle first.

Yes, those are valid points. But handling them can by quite tricky, especially
on windows ;-))



* Dipl.-Math. Jürgen Hunold       ! Ingenieurgesellschaft für 
* voice: ++49 511 262926 57       ! Verkehrs- und Eisenbahnwesen mbH  
* fax  : ++49 511 262926 99       ! Lister Straße 15
* juergen.hunold_at_[hidden]        !
* Geschäftsführer:                ! Sitz des Unternehmens: Hannover
* Prof. Dr.-Ing. Thomas Siefer    ! Amtsgericht Hannover, HRB 56965
* PD Dr.-Ing. Alfons Radtke       !

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at