idea about improving moc support

[LiuCougar]

On 10/15/05, Nagy Thomas <tnagy256 at yahoo.fr> wrote:
>
> > There are some issues with current moc support in
> > bksys:
> > 1. Each invoking of scons, each cpp file is scaned
> > to find moc includes;
> > 2. Even every cpp file is scaned, the current
> > implementation still
> > requires us to specify additional header files to
> > generate extra moc
> > files
> >
> > As scons built-in sourcescanner scans every source
> > file for includes,
> > it would be better if we could incorporate the moc
> > scanner there. The
> > attached two patch files was an attempt to do that:
> > please apply the automoc file in the kdelibs topdir,
> > and apply the
> > other file to
> > scons-local-0.96.91/SCons/Scanner/__init__.py (This
> > is
> > the side effect of this: the scons needs a little
> > patch to work with
> > this new mechanism)
> >
> > The approach is to replace the standard
> > sourcescanner with a custom
> > one, which will take care of moc files
> > automatically.
> >
> > There will be only one scan if the source file does
> > not change, and no
> > moc file (even those private one) does not need to
> > be specified
> > manually in SConscript files (see the automoc
> > patch): so the above two
> > issues in current implementation are solved.
> >
> > However, there are 2 new issues, which I think
> > should be possible to fix:
> > 1. moc files are created in source dir, rather than
> > the build one
>
> The name of the moc file in the source directory is
> given, not the name of the moc file in the build
> directory.
Right, I fixed this in the attached new automoc patch file

> Something in FS.py is probably needed:
> def srcnode(self) -> def tgtnode(self)
>
> > 2. after the target is built successfully, if you
> > remove all *.moc
> > files, scons has no idea how to generate it again
>
> > Do you think this is the right way of handling moc
> > files?
>
> The idea is good, but you might want to have a look at
> the scons Qt.py - last time i checked it rescanned
> files too - but it may have changed.
Yes, I already checked that qt.py file, and it still scans everytime

> You may also want to check if such an optimization is
> necessary by the way: in qt4.py, scan_moc, look at the
> existing moc files and compare the running times with
> and without scanning. Last time i checked (kdissert)
> they were not necessary for kdissert.
In the patch, scan_moc is disabled
I did not compare that yet, but I assume that for big project, like
kdelibs, it will for sure gain some performance.

> Retrieving dependencies (scan results) from nodes
> would be a good idea too by the way.
I thought that as well, but I just can not figure out how to use the
scons cache to save these kinds of info. On the other hand, the new
approach only scans once (however, there is still an outstanding
issue)
--
"People's characters are strengthened through struggle against
difficulties; they are weakened by comfort."
- Old Chinese adage
-------------- next part --------------
A non-text attachment was scrubbed...
Name: automoc
Type: application/octet-stream
Size: 7902 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20051015/01c831ab/automoc-0001.obj