Even after
http://cgit.freedesktop.org/libreoffice/core/commit/?id=39c3a4d6644ae78783aa8877557e4c021cba7973
idlc: clear include file set in Idlc::reset(): the problem described
at the start of the below #libreoffice IRC transcript still remains.
(Which is only logical, as merely touching an .idl causes cppumaker to
not actually write fresh target .{hpp,hdl} files as they remain
unchanged, so bogus excess dependencies among .idl files cannot explain
the phenomenon anyway. It is still so that commenting out the touch
$@ recipe would solve the observed problem, but with side-effects
unclear to me.)
Sep 05 13:26:22 sberg mst__, dtardon, I'm still troubled why touching one
offapi/com/sun/star/X/Y.idl causes many
workdir/*/UnoApiHeadersTarget/offapi/normal/com/sun/star/X/*.{hdl,hpp} to be generated with fresh
timestamps; it is apparently not a problem of cppumaker not detecting that the contents of the
generated .{hdl,hpp} did not change (in which case cppumaker does not touch the targets); rather,
commenting out the touch $@ recipe for the $(call gb_U
Sep 05 13:26:22 sberg nOApiPartTarget_get_target,%.urd) rule near the top of
solenv/gbuil/UnoApiTarget.mk would make that phenomenon go away -- but what that purpose
that serves exactly is beyond my gbuild skills
Sep 05 13:27:14 sberg to witness: touch offapi/com/sun/star/mail/MailServiceType.idl
make offapi ls -lt workdir/*/UnoApiHeadersTarget/offapi/normal/com/sun/star/mail
Sep 05 13:30:22 mst__ sberg, iirc the problem is that the rule with the
touch in it cannot tell whether the file has been modified by cppumaker or not
Sep 05 13:32:11 mst__ sberg, if you remove the recipe there then make will not
propagate the out-of-date-ness across this target so that e.g. the hdl/hpp file is
not delivered and cxx files that include it are not rebuilt (that will happen on the _next_
make invocation only when make actually checks the timestamp of the generated .hdl/.hpp files)
Sep 05 13:32:49 mst__ sberg, right now it's not optimal but i'd rely on
ccache for this case :)
Sep 05 13:34:45 sberg mst__, but the question is what exactly causes the
collateral touches for other unrelated offapi/com/sun/star/X/Z.idl, and whether
something could be done about that --and there's no ccache on Windows :(
Sep 05 14:35:39 mst__ sberg, i forgot that there is another wrinkle to it:
only the headers from IDL files that include the file that you change will be
touched: grep -l -r MailServiceType
workdir/*/Dep/UnoApiPartTarget/offapi/com/sun/star/mail/
Sep 05 14:43:59 sberg mst__, ah; but which in turn begs the question why e.g.
workdir/*/Dep/UnoApiPartTarget/offapi/com/sun/star/mail/SendMailMessageFailedException.d
mentions MailServiceType when the .idl does not (neither directly nor indirectly)
Sep 05 14:45:15 mst__ sberg, that .d file is generated by idlc from the files
that the preprocessor sees - it wouldn't surprise me if there's a bug in there that
stuff is missing, but it shouldn't make up dependencies that aren't there?
Sep 05 14:45:48 sberg mst__, I guess that's somehow due to idlc being called
to process types en-block?
Sep 05 14:47:11 mst__ sberg, oh wait... that is odd... the size of the .d
files increases monotonically with the modify date... possibly something isn't
cleared between files?
Sep 05 14:53:15 mst__ sberg, it seems Idlc implements the dreaded singleton
anti-pattern, i didn't expect that :-/
Sep 05 14:53:40 sberg mst__, how come you didn't ;)
Sep 05 14:59:52 mst__ sberg, aha... clearing the includes in reset() takes
the offapi.d from 41M to 4.5M ... why didn't you notice this earlier :)
Sep 05 15:00:56 sberg mst__, :)
[enter 39c3a4d6644ae78783aa8877557e4c021cba7973]
Sep 07 10:12:33 sberg noelg, do you also experience that when you change a single
offapi .idl file, a following toplevel make recompiles almost everything? looks
like __mst's recent idlc fix is not yet enough
Sep 07 10:15:21 noelg sberg, indeed that is the case, I thought it was just
because a lot of files were dependent on the IDL stuff
Sep 07 10:16:14 sberg noelg, no, looks like a bug; will look into it/poke
__mst again
Sep 07 10:16:58 noelg sberg, that would be nice, even with my 6-core box, all
that building takes a while :-)
Sep 07 10:17:57 sberg noelg, yep, same here
Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
