On 06.04.2011 19:47, Michael Stahl wrote:
On 06/04/2011 18:45, tora - Takamichi Akiyama wrote:
Hello Christian,
On 2011/04/06 20:55, Christian Lippka wrote:
While Niklas and Daniel are absolutely right, make clean may not always
be what you want.
For example, if you just want to rebuild svx with debug and do a
make -sr clean, your next make in sw module would rebuild a lot of
stuff, since all dependency to svx would fire.
actually, for a module like svx it shouldn't rebuild any cxx files in
dependent modules (which takes up most of the time), because gbuild will
preserve the timestamp of the original file when delivering.
of course if headers are *generated*, then dependent cxx files will be
rebuilt.
hmm... on second thought, if you actually use the top-level makefile, then
probably the cxx files will be rebuilt in this case... :(
If "in this case" means: "if there are generated headers", this is true.
And IMHO it's the only way a sane build system should work. A build
system that relies on "manual" evaluation of dependencies by developers
(as the build.pl/dmake combo) is insane. Dependency evaluation is what
make tools and files are made for.
In case of svx/sw the generated header files svxslots.hxx and
globlmn.hrc cause some rebuilds in sw. Perhaps this is a good starting
point to think about better dependencies. Files like these and the way
we are using them are annoying. We can do better.
globlmn.hrc is doomed once we get the work to get rid of context menu
resource files finished.
In case we moved all slot files into a single module and build them only
if sdi files have changed, the second problem would be solved also. This
would treat sdi files pretty much like idl files.
The number one reason why changing header files causes too much rebuilds
is that our classes and thus our header files are too large (so that
"including only what you need" doesn't work), that we have still too
much nested includes and that superfluous includes in source files
rarely get removed.
Regards,
Mathias
--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS
Please don't reply to "nospamfor...@gmx.de".
I use it for the OOo lists and only rarely read other mails sent to it.
--
-----------------------------------------------------------------
To unsubscribe send email to dev-unsubscr...@openoffice.org
For additional commands send email to sy...@openoffice.org
with Subject: help
