Hi Kai, > This objection seems to come up now and then, so I wanted to make sure > we are talking about the same kind of full program dependencies. > ... > > Now, if sw depends on svx/inc/svxids.hrc everything along that path will > be re-generated. Again if sw somehow depends on dbaccess which depends > on dbtools.hxx it -will- get regenerated. If you build the "debug" target > the whole app will get regeenrated, based on what has changed.
I don't know about different targets and the like, so I'd lie ;) if I'd say I completely understood your description, but I think we're on the same track. > So just to make sure, if sw depends on svxids.hrc and/or dbtools.hxx you > object against regenerating the intermediate libraries? Yes. See below. Some side note: If I'm correct, those full dependencies are already active today in OpenOffice.org builds, but not in Sun Hamburg internal's build environment. I know the latter for sure, and I seem to remember the former from when I built in an OOo build environment myself (though I only got this impression when playing around, but never really verified.) I always assumed this is because in a usual OOo build environemnt, solenv (and thus all delivered files) are below $SRC_ROOT, while in a Sun Hamburg build env, it is outside $SRC_ROOT. So, if in an OOo build, I touch svx/inc/svxids.hrc and deliver it, then all depending files in sw get recomiled. Right? > - The build system is generally conservative in dependency checking. If it > can reasonably deduct that something is included it -will- recompile the > specific cxx file. Generally speaking this is the correct approach, proving > that the change does not impact a .cxx is a hard problem (as you very well > know). So if you muck around with svxids.hrc the build -should- recompile > everything depending on it as that's the only reasonable way to figure out > if you change really worked (you might have done a mistake that impacted > all files). The original idea behind the incomplete dependencies, as I understand it, was to save build time. There *are* changes which are simply, affecting say 2 files only, where the build system would, if ran with full dependencies, effectively recompile the whole tree. Imagine, for instance, adding a new method to ::rtl::OUString. This is a highly compatible change (in fact, "compatible" in the minds of most Sun/Hamburg developers means this: a change which does not have cross-module effects, except in the files which use this change), but the build system would nonetheless burn quite some cycles on recompiling everything, without a real need. Even aside this extreme example, there's enough other cases, as I tried to outline. Of course, not having a full-blown dependency tree means giving the developer more responsibility for what s/he's doing (hey, I remember having been asked about compatible vs. incompatible changes when I was hired by StarDivision - they really made sure people understood this before working on the code :). > - The recompilation is generally much faster (almost a magnitude for some > pieces of the code) so it might be below your pain threshold anyway. E.g. > recompiling all of sc is a matter of minutes. Heck, what machine are you compiling on? :) Recompiling all of, say, dbaccess or connectivity or svtools or svx or extensions (modules where I usually work) takes *much* longer (at least on Windows), and they are smaller than sc. So: No, I really consider build time an issue here. (and I'm talking about Windows local builds only. Building a Windows OOo on a network machine takes *days*! With complete dependencies, this is more likely to hit us ...) > - In case you really need to be more agressive and -know- your change > doesn't impact any other code I'm sure I can add an option to temporarily > disable dependency checks. -You- probably have enough experience to > know when to use it, but I'm sure many of the newer developers (me > included) would shoot themselves in the foot with such an option. We -need- > to be able to regenerate all files for our own safety. Maybe we could call > the option --enable-ace-developer or something .. :-) This is probably hard to achieve in a fine-grained manner, but would be useful on a per-global-build basis, I think. > - If this really is a huge problem for some files, the question is > how we could improve the physical layout of the code to resolve it > completely? Could we split up the *ids.hrc files somehow to make this > less of a burden? How about the other files that are included > everywhere? I think we can't ... .hrc files (used to collect dozens up to hundreths of defines) are only one problem. (we even once split up such a .hrc file internally in dbaccess, for use in various sub locations, since compile time was already an issue module-internally. This halfway helps, but not too much ...) The other problem are methods on classes - as long as they're not virtual, touching them only needs to recompile their clients, but not all clients of the whole class. And this is something you can only split in theory (by, ehm, more sophisticated coding methods :), but not in practice. Look at all those vcl/tools/svtools classes, which usually are a large pile of losely related functionality, where every now and them somebody adds or changes some minor things ... Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
