I think my position is about the same as Terry's.
I also think we have a precedent for building everything that is
possible and letting the user choose at run-time what they want to
do. My $0.02 is that it's easier to tell random users (and
customers!) "yes, OMPI should have built that for you by default; you
use it like this..." vs. "No, sorry, you need to go re-install OMPI to
have feature X."
We developers are probably a bit more sensitive to this issue since it
makes longer builds (and we re-build all the time). But remember that
most people install OMPI only a small number of times -- so build time
is less of an issue for them.
(I'm assuming that at least one of your motivations for asking was the
longer build time...?)
On Feb 1, 2008, at 10:17 AM, Terry Dontje wrote:
> Josh Hursey wrote:
>> Should the default be to *disable* vampirtrace?
>> I mention this since, I assume, most people do not depend on this
>> tool for every Open MPI install. Meaning that Open MPI does not
>> require this integration for correct MPI functionality unlike
>> something like ROMIO [example of opt-out functionality which is 3rd
>> So I would suggest to the group that vampirtrace be an opt-in
>> What do others think?
> I am not completely against disabling it as a default. However,
> once it
> builds consistently having it enabled by default shouldn't really
> any problems for those not directly using it (well outside of more
> to compile). I imagine changing the default probably would help ORTE
> move forward but then I wonder if we will run into issues of the
> stuff not being able to resolve their issues because of ORTE problems
> put back to the trunk.
>> -- Josh
>> On Jan 28, 2008, at 9:59 AM, Andreas Knüpfer wrote:
>>> Hi everybody,
>>> the vampirtrace integration arrived at the trunk today. There seems
>>> to be one
>>> issue already, but we'll fix this asap.
>>> As a general hint, this is how to completely disable anything we
>>> configure --enable-contrib-no-build=vt ...
>>> Then again, we'd like to see all the issues you may encounter and
>>> fix them.
>>> Best regards, Andreas
>>> Dipl. Math. Andreas Knuepfer,
>>> Center for Information Services and
>>> High Performance Computing (ZIH), TU Dresden,
>>> Willersbau A114, Zellescher Weg 12, 01062 Dresden
>>> phone +49-351-463-38323, fax +49-351-463-37773
>>> devel mailing list
>> devel mailing list
> devel mailing list