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

From: Felix E. Klee (felix.klee.jamboost_at_[hidden])
Date: 2003-01-16 04:40:18

On Thursday 16 January 2003 08:57 am, Vladimir Prus wrote:
> >>1. User explicitly specifies the list of headers that must be processes
> >>with MOC, for example
> >>
> >>qt.exe hello : hello.cpp hello.h ;
> >
> > IMHO, this solution has two disadvantages. Firstly, the user has to
> > change the header file list almost each time he adds or removes a
> > Q_OBJECT. Secondly, you need to introduce extra target types (qt.exe,
> > qt.lib, etc.).
>
> 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.

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

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

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

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

Felix

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