Re: [jamboost] Qt: moccing of cpp sources

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-09-08 05:13:33

Hi Jürgen,

> 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
>
> http://doc.trolltech.com/4.0/moc.html
>
> 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.

Noted.

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

- Volodya

-- 
Vladimir Prus
http://vladimir_prus.blogspot.com
Boost.Build V2: http://boost.org/boost-build2