From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-09-08 05:13:33
> On Dunnersdag 08 September 2005, 11:19, Vladimir Prus wrote:
> > Hi Jürgen,
> > I'm working on making .cpp files moccable at the moment. My current
> > syntax looks like this:
> > exe main : main.cpp
> > [ cast _ moccable-cpp : main.cpp ]
> > /qt//qt ;
> > Where 'moccable-cpp' is a new type of files, needed to indicate that we
> > want to invoke moc on them, 'cast' is a new main target, and '_'
> > essentially means "I don't want to provide any name".
> The name then will be "main.moc", I hope ?
No, "main_moc.cpp" at the moment.
> > That's fine, but so far V2's Qt tool simply compiled the files generated
> > by moc, and did not require to #include the result. It will be
> > inconsistent if we require #include for moccing .cpp files, and don't
> > require (and in fact prohibit) #include for moccing .h files.
> Well, please take a look a TrollTechs documents at
> and take a look at the section
> "Writing Make Rules for Invoking moc".
> TT distinguishes between .h and .cpp.
> They suggest to moc and compile .h files
> and to moc and #include .cpp (implementation) files.
> I think we should follow this suggestions because qmake works this way.
> And most users willing to switch to bjam will probably either migrate from
> qmake or have handwritten Makefiles following these suggestion.
Yes, that makes sense.
> On the other I know that the KDE project _always_ #includes the mocced
> files in order to get some speed improvements.
Hmm... in fact I don't know if I can have .cpp files mocced with current KDE
build system, so I always put Q_OBJECT classes to headers.
> But they are switching to Scons at the moment...
Are they? I haven't see any news about this on KDE mailing lists.
> > What will the users say if I change Qt support to always require
> > #including" the output of moc?
> This user says it will break *every* project I have *ever* worked on.
> That's because we use qmake and Visual Studio.
> If we want to support both schemes we need a configurable switch in each
> Jamroot, IMHO.
Okay, I'll first make the qmake-compatible way work, and then wait if somebody
requests a switch.
-- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build V2: http://boost.org/boost-build2
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