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

From: Felix E. Klee (felix.klee.jamboost_at_[hidden])
Date: 2003-01-17 08:55:29

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.

To clear things up, here's what the QT 3.0.5 documentation says:

HEADERS

Defines the header files for the project.

qmake will generate dependency information (unless -nodepend is specified on 
the command line) for the specified headers. qmake will also automatically
detect if moc is required by the classes in these headers, and add the
appropriate dependencies and files to the project for generating and linking
the moc files.

For example:

HEADERS= myclass.h \
login.h \
mainwindow.h

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.

> Upon invocation
>
> > it scans these headers and adds moc targets to the Makefile for all
> > headers requiring it.
>
> Yes, it requires you to list all headers that eventually need moc'ing

No, not exclusively, see above.

> > 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++.

> > 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).

> >>2. Auto-detect the list of mocced headers. But this is non-trivial. (And
> >>non-explicit).
>
> Autodetecting headers that need to be moced is just overkill. 

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.

> FWIW here is what I use with v1.

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?

Felix

-- 
To contact me personally don't reply but send email to 
felix DOT klee AT inka DOT de