Hi Frank, 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.
Let's say you are building the target debug-sw. In theory this is what happens (in practise things are more optimized): first the build generates a complete dependency tree for the whole application rooted at the "all" target. This includes all different build variants (debug, release) and all modules. Then it finds the debug-sw target and re-roots the tree here. Now everything that debug-sw doesn't depend directly or indirectly on is pruned away (as this is a DAG it's easy to do). 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. So just to make sure, if sw depends on svxids.hrc and/or dbtools.hxx you object against regenerating the intermediate libraries? -- In case you do, I'd love to understand this issue better. Here are some comments on it: - 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 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. - 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 .. :-) - 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'd love to hear your input on this. Thanks for the feedback, it's great to hear what you are really looking for in the build. Take care, Kai On 6/28/06, Frank Schönheit - Sun Microsystems Germany < [EMAIL PROTECTED]> wrote:
> - Full dependencies - including over module / project borders: While > changing a (inline) header e.g. in SAL, I want everything dependent to > be build, nothing more, nothing less. No, please do *not* turn this on in general. With the file structure in especially some older code parts, this would be hell. I definitely do not want to compile the complete application modules (and more) just because I added a new ID to svx/inc/svxids.hrc. I do not want to compile complete (for instance) dbaccess, just because I added some new helper method to connectivity/inc/connectivity/dbtools.hxx. I do not want to compile the complete source tree just because I added a new, non-virtual method to ::cppu::OPropertySetHelper. You get the idea ...
-- Kai Backman, Software Engineer, [EMAIL PROTECTED]
