On 08.04.2011 11:19, Michael Stahl wrote:
On 07/04/2011 10:05, Mathias Bauer wrote:
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.
no, i mean for ordinary headers that are just copied.
(that generated headers cause rebuild is really obvious...)
for headers that are just copied, GNU make will consider the target in the
outdir outdated, because, well, it doesn't exist, and will copy the header
to the outdir.
Ah, I see. I just overlooked that you talked about build after "make
clean". Sorry.
of course the right question here is, why the hell are we copying all
those headers?
it seems pointless to me: they could just as well be included from the
source directory instead of from the solver.
I agree. OTOH this would be a huge change. The current way we include
our headers from outside the current module assumes that they reside in
a common root folder. If we took them from their location in the source
directory, we either had to move all currently "delivered" header files
into a common source directory or we had to change all include
statements (e.g. from "#include <sfx2/objsh.hxx" to "#include
<sfx2/inc/sfx2/objsh.hxx>".
The third option to add all modules to the INCLUDE path is a no-go for
performance reasons.
There is a fourth, somewhat pragmatic option: add a second clean target
that does't remove headers that are only copied but not generated.
For those who now start to think that the rebuild caused by a "make
clean" is a bug in the new build system: that's not true. The bug is
that we copy header files in the build instead of using them where they are.
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
