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$...
Thanks
Edgar
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
correspont
to two tasks: firstly, decide if you want vampirtrace at all or (if
you might
want to update) and secondly, passing configure options to
vampirtrace.
we need to do the first before the second, of course. maybe we can
move
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
openmpi
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
openmpi.
therefore, they stay next to 'mpicc' and all others. in fact we're
following
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
everyone?
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.
--
Edgar Gabriel
Assistant Professor
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
