Frank,
Frank Schönheit - Sun Microsystems Germany wrote:
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".
Understood.
- 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.)
I am pretty sure, that we are only going to introduce something new, if
we can agree on it to be an improvement, at least to not be a regression.
- 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.
Yep, that is the hope.
- 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.
See above.
- 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 :)
I tend to disagree here (oh well, there do not seem to be too many
topics for which we seem to have similar opinions, anyway :-), if you do
not want to show the internals of your implementation, I suggest to
introduce an "interface" and to provide a public factory function only.
Providing a public class having a impl pointer member only, seems to be
useless.
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.
OK, if you say so, I believe you ..., so it is all by design :-)
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.
Just think of the myriads of open source developers wanting to help us ...
However, in my opinion, the increased average efficiency in the daily
work is worth this trouble from time to time ...
Mmmm, several times I had to fix "bugs" which just were build problems,
because of not understood dependencies.
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 ...
This is IMHO another story, but still very valid to be solved as well.
Ciao
Frank
Kay
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
