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:
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.
HEADERS= myclass.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
> 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.
> 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?
-- To contact me personally don't reply but send email to felix DOT klee AT inka DOT de
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk