Hi Ralph,
> I don't have an opinion either way on this specific proposal. However, I do
> have a growing concern over the number of packages being added to the
> system, all of which want to "build by default". The build time is already
> long and rapidly growing, and our code distribution is correspondingly
> increasing in size.
>
> I therefore would like to raise two areas for thought:
>
> 1. Do we need to, at some point, begin to ask if all these packages -have-
> to be included as source code in our code base? Can we devise a means such
> that people could download them separately and link the libraries to us in
> some other fashion?
yes, they can of course. It's actually a very similar discussion as for
VT - it's all about usability and ease of use. And also getting into the
testing cycles etc.
> 2. Have we applied the "rational thought" filter here - i.e., are we
> building by default what a large percentage of the user community will use,
> or are we building by default all things that somebody, somewhere, someday
> -might- use? If the latter, is that really how we want to define the
> "default" build?
I do not know how large the user base will be. I know of some
applications that implement their own non-blocking versions of
collective operations. However, building those things does not really do
any harm.
> For example, as a first step on #2, wouldn't it make more sense to at least
> have the build system -not- build some things by default when in "developer"
> mode, but build by default when doing an optimized installation? This would
> save those of us who have to build frequently from all the time penalties of
> building things we have no use for in our daily work (which is becoming a
> significant part of the code base), while retaining this "build everything
> conceivable" approach. I suggest this only because, while I certainly -can-
> turn it all "off", the number of options required to turn off all these
> unneeded "default" code areas is becoming large, and constantly seems to be
> growing.
Yes, I would agree to this. Not that I disagree on your other points,
but they certainly have to be decided by the community. And as far as I
know, the community agreed on having non-blocking collectives on the
"roadmap" for 1.3. The question is if we do want this on our feature
list or not (cf. ROMIO, it's also perfectly fine as a separate library,
but we bundle it just because the standard says so). We just decided to
use the "light" and less error-prone variant to do this (the other idea
was to extend the coll modules to offer non-blocking collective
support).
Best,
Torsten
--
bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ -----
Indiana University | http://www.indiana.edu
Open Systems Lab | http://osl.iu.edu/
150 S. Woodlawn Ave. | Bloomington, IN, 474045-7104 | USA
Lindley Hall Room 135 | +01 (812) 855-3608
