hi!
Frank Schönheit - Sun Microsystems Germany wrote: > 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? would be a surprise to me. AFAIK, using "nodep=TRUE" is used rather than even module wide dependencies as the builds are done as "clean builds" anyway. > >> - 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 ...) > from my point of view, these valid concerns about complete dependencies can only be answered by pure build speed. that's what kai is promising. so the main point to me is to lower the price for an usefull feature so it gets usable in daily work. if build times, even with complete dependencies, can be lowered that dramatically as some of kais data suggest, it's the point to think of migrating to jam instead of dmake. so i'm eagerly waiting for the first "jam build" prototype to get my hands on ;) >> - 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 > > tschau... ause --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
