Hi Kay, > - You are certainly free, to build one module only.
No. My daily work plays in multiple modules usually. They depend on each other, but not necessarily all changes I do in both do so. That is, if I change a header in module A, I will sooner or later need to compile module B because of a completely unrelated change. Full dependencies would then force me to recompile complete B. Sorry, but you're making it too easy with "simply don't compile the other modules". > - There are techniques, which allow to not necessarily rebuild > everything dependent on a particular file, just because a comment was > added. E.g. http://abisum.sourceforge.net/ may be used, to check if > relinking is needed. Other such approaches may apply to resource or > header files. If those techniques are introduced the same time full dependencies are, and if we have them for all relevant cases (in particular .hrc files with mere ID definitions), then that's okay. Else, pointing to some future "but we could optimize this with ..." doesn't really help. (Of course, all of what I'm saying here is assuming that build times would still be an issue. If they aren't, as Ause said Kai's data suggests, then this is meaningless.) > - As reported by Kai, at least 66% of the build time is currently spend > in outer tools (dmake, perl, makedepend, ...), so there seems to be > space for improvement. That in fact sounds promising that work here could heavily relax the build time problem. > - AFAIR, the original reason for not using global dependencies was > network build performance, which degenerated because of the many file > stats. That might be. Still, with link times (on Windows) in the range of multiple minutes for the main application modules, every file built without necessity is one file too much. > - My impressions is (and you may very well correct me if I am wrong), > that quite many people spend time, effort and code (->impl constructs) (That's a bad example. The PIMPL idiom is not only used for memory layout compatibility, but for other reasons, too. Even with full dependencies, I would consider it a good approach to hide implementation details in an impl construct, finally that's nothing the clients need to see, or be tempted to play with :) > into avoiding or understanding in-compatibility, basically to not > increase development build times. So, deficiencies in build time become > addressed by application _code_! Improved build performance and full > dependencies are the way to solve this. I'm not sure about this. As outline above, I don't think we really address those in the code. I agree that the current state, without complete dependecies, causes trouble and wasted time on developer side, in those cases where you _missed_ a dependency which you should have handled manually. And yes, the less experienced a developer is, the more probable it is that s/he will be bit by this. However, in my opinion, the increased average efficiency in the daily work is worth this trouble from time to time ... I would more appreciate if we could resolve some of those troubles, for instance the .def file constructs on Windows, which sometimes make it pretty easy to become incompatible, and hard to get rid of an incompatibility once you have it ... 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]
