|
Boost-Build : |
From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-01-16 05:01:02
Felix E. Klee wrote:
>>Speaking of the first, is this a problem in practice. As I understand it,
>>qmake requires to declare all mocced header, too.
>
>
> qmake requires you to list all headers in the current project. Upon invocation
> it scans these headers and adds moc targets to the Makefile for all headers
> requiring it.
OK.
>
>
>>To avoid it, one can:
>>
>>1. Use "moc_h" extension for headers and then do
>>
>>qt.exe hello : hello.cpp [ GLOB . : *.moc_h ] ;
>>
>>However, your observation still applies: it's another way to explicitly
>>specify the list of mocced files. If you add Q_OBJECT, you need to change
>>that list. And in this requires file renaming. (How do you do that
>>in CVS, for one thing?)
>
>
> Yes, but I like really this solution because, as David pointed out, these
> header files are actually non-C++ source files. I recommend ".qpp" as an
> extension which fits nicely with the common ".hpp" and ".cpp" extensions.
OK, and ".qpp" will be "header file that should be processed by moc"?
You'd still have to add the files to the list of sources, right?
>>2. Auto-detect the list of mocced headers. But this is non-trivial. (And
>>non-explicit).
>
>
> I don't like this solution anymore. IMHO, treating the headers to be moc'ed as
> source files is cleaner.
OK.
>>About the new targets types: what's wrong with them? They'll be derived
>>from corresponding general types, e.g qt.exe will be derived from exe.
>
>
> What if eg. Fortran support is added in the future (or is it already?). Then,
> infering from your proposed notation, a user might have to write eg.
>
> qt.f.exe hello : hello.cpp hello.f hello.h ;
>
> if he uses Fortran and Meta Object enhanced C++ sources in the same project.
No, the F -> OBJ transformation will be added, and you'll write
qt.exe heloo : hello.cpp hello.f hello.h ;
The reason we don't need additional type is that ".f" suffix identifies the
file type. I did not want "h" files to be mocced even in ordinary "exe"
targets. But.. if you use "qpp" extension, this problem goes away.
>
>
>>In fact, they would only add <qt.moc>on feature to the properties.
>
>
> I'm not sure anymore if such a switch is neccessary at all if the Meta Object
> enhanced headers are treated as source files (I know, I keep repeating
> myself). But then again, I don't understand enough about the Jam architecture
> yet.
Indeed. I'd have only to tell Boost.Build that *QPP files can be converted to
*MOC.CPP by calling moc. Hey, I like the "QPP" solution!
- Volodya (who's just about to start hacking on it)
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