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
