Jeff Squyres wrote:
> Is this in the production VT, or is this OMPI-specific functionality?
> If it's OMPI-specific functionality, I would vote to not have it.
> One of my big problems with this idea is that we lose the concept of
> shipping a single unit of Open MPI. If someone sends us a bug report
> concerning VT, we no longer have a solid idea of what version they
> are running because they may have replaced the one inside their Open
> MPI software.
well, this issue could be however resolved, if ompi_info and friends
would have a way to report the precise version number for VT, isn't it?
Without having any strong feelings one way or the other, I think that
the functionality is great from the end-users perspective. Just my 0.02$...
> Running an external VT install OMPI is a different thing; that's easy
> enough to tell that someone is not using the included VT vs. an
> external VT. But if the user is able to arbitrarily (and perhaps
> accidentally) change the included VT, this becomes problematic for
> support and maintenance.
>> - about the two vampirtrace-specific spots in the .m4 files: they
>> to two tasks: firstly, decide if you want vampirtrace at all or (if
>> you might
>> want to update) and secondly, passing configure options to
>> we need to do the first before the second, of course. maybe we can
>> everything to "our" .m4 file, let me check ...
> I would think that all OMPI-specific VT functionality should be in
> one .m4 file. Per my other mail, I think it should be in contrib/vt/
> configure.m4. This makes a nice, clean separation of m4
> functionality and keeps it self-contained into the contrib/vt/ tree.
>> - btw: so far the vampirtrace distribution tarball is brought to
>> under ./tracing/vampirtrace with no modifications
> Excellent. That makes things considerably easier.
>> - the mpicc-vt (and friends) compiler wrappers: this is not part of
>> vampirtrace but a new thing that only makes sense together with
>> therefore, they stay next to 'mpicc' and all others. in fact we're
>> a earlier suggestion from you, Jeff: 'mpicc-vt' is just like
>> 'mpicc' but
>> calls the 'vtcc' compier wrapper instead of 'cc'.
>> this makes everything much simpler, because we can handle all
>> special cases in
>> vtcc. the wrapper config for 'mpicc-vt' is almost a mere copy of
>> mpicc's one.
>> therefore, I'd like to keep them where they are right now. is this
>> o.k. with
> I like the idea of mpicc-vt (etc.) wrappers, but again, I think they
> should be consolidated in the contrib/vt tree. There's no technical
> reason they need to be in the wrappers directory.
> More specifically, I am uncomfortable with importing 3rd party
> packages that touch a whole bunch of places in the OMPI tree. I am
> much more comfortable with 3rd party packages being self-contained.
> I hope to have the libnbc integration done either this week or next
> as an example. We're still far enough away from v1.3 release that
> this does not impact any release plans with VT.
Parallel Software Technologies Lab http://pstl.cs.uh.edu
Department of Computer Science University of Houston
Philip G. Hoffman Hall, Room 524 Houston, TX-77204, USA
Tel: +1 (713) 743-3857 Fax: +1 (713) 743-3335