Re: [jamboost] Adding QT support to Boost Build V2

From: Jürgen Hunold (hunold+lists.Boost_at_[hidden])
Date: 2003-01-17 09:17:10

Hi ! 

It seems I have to give my .02 ¤ to the discussion... 

On Friday 17 January 2003 14:55, Felix E. Klee wrote:
> On Thursday 16 January 2003 05:03 pm, Thomas Witt wrote:
> > > qmake requires you to list all headers in the current project.
> >
> > No it doesn't.
...
> So, yes, you need to specify all the headers in the current project
> that you want to be included in the dependency graph. And those,
> often, are not just the headers that need to be moc'ed.

I'm still using qmake and it works without having all moc files in the 
HEADERS-section. 
The point is, that these non-moc headers are likely to be included in 
some .cpp somewhere and enter the dependency graph at that point. No 
need to take further action... 
Well, I've never tried the "make install" options of qmake, where _all_ 
headers are needed.

> > > Yes, but I like really this solution because, as David pointed
> > > out, these
> > >
> > > header files are actually non-C++ source files.
> >
> > Again, as Vladimir already said, they are ordinary C++ source
> > files.
>
> Those files contain Meta Object enhanced C++ code. Meta Object code
> has been designed so that a C++ compiler doesn't complain when seeing
> it (that's actually neccesary when including them in other files).
> But it still is an extension to C++ and not standard C++.

corrrect. *sigh* that it the problem and the cause of many problems...

> > > I recommend ".qpp" as an
> > >
> > > extension which fits nicely with the common ".hpp" and ".cpp"
> > > extensions.
> >
> > I strongly object against the idea of using a special extension
> > for these files it is just unneeded.
>
> Why? I don't understand what is so bad about a special extensions
> when these files aren't standard C++ source files. OTOH when used as
> header files they are treated like normal C++ code. So, thinking a
> bit about it, I'm not so sure anymore if we really need a special
> extension ... yes, I think you are right, and it is indeed unneeded
> (see also below).

Good. Some examples from me.
I've switched from handwritten-Makefiles to qmake and plan to switch to 
bjam v2 when I've the time.

I've literally hundreds of headers with Q_OBJECT in them lying around 
here.
Please think of the steps necessary to add a Q_OBJECT to a header:
change a.h -> a.qpp
change x.cpp to #include a.qpp
When you use CVS (we do), you have to
remove a.h, add a.qpp which is not recommend by CVS, causing much grief 
and loss of file-history.
commit x.cpp

And think of doing this to several hundred files for initial change. My 
collegues will try to kill me....

> > >>2. Auto-detect the list of mocced headers. But this is
> > >> non-trivial. (And
>
> I don't like that solution anymore as well.

> > IIUC this
> >
> > is also doomed to fail. You may well include library headers that
> > contain Q_OBJECT macros that you don't want to moc.
>
> True.

> If moc'ing can be turned on and off with some kind of "moc" switch
> then a solution where ".h" files are specified as source files is
> actually OK with me. But I recommend renaming ".h" to ".hpp" (that's
> more Boost compliant) or, even better, letting the user specify the
> extensions with a subfeature. Maybe that approach can be extended
> into a general approach for supporting files that can be processed
> but don't need to. Another example besides moc would be extracting
> documentation from C++ source and header files using tools like
> Doxygen. What do others think?

Well. As stated above, each "special" extension causes much work with 
existing projects. For me, this is just inacceptable.
I'm using Thomas' jamrules for my experiment with v1 and it works very 
good.
And we're using doxygen to generate docs out of _every_ header.

Yours,

Jürgen

-- 
* Dipl.-Math. Jürgen Hunold ! Institut für Verkehrswesen, Eisenbahnbau
* voice: ++49 511 762-2529 ! und -betrieb, Universität Hannover  
* fax : ++49 511 762-3001 ! Appelstrasse 9a, D-30167 Hannover
* hunold_at_[hidden] ! www.ive.uni-hannover.de