Changing .idl still causes excessive .{hpp,hdl} touching

[Stephan Bergmann]

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