On Oct 8, 2007, at 10:00 PM, Andreas Knüpfer wrote:
- yes, we might move vanmpirtrace to ./ompi/contrib/vampirtrace/,
why not. but since we agreed on the current location ./tracing/
vampirtrace/ we should not rush it just because another software is
coming to openmpi, should we?
I actually always had in my mind that VT should live somewhere under /
ompi -- not in the top-level directory. I'm sorry if I did not
communicate that well.
- the "call home" feature. I understand you concerns perfectly
well. we'll
remove this, If anyone is asking us to. but please let me explain
first:
1) it's not in vampirtrace itself but in the parts we added to ompi
on behalf
of vampirtrace
2) it is never active by default, instead you need a
special '--update-vampirtrace' switch on your configure command.
otherwise
nothing is calling nowhere. is this equivalent to "totally
deactivated" or
still not good enough?
3) it was our idea to make it easier to replace the included
vampirtrace
version if it was necessary. manually download and untar is not
that much
harder, though.
4) we check if 'wget' is present and try _not_ to make ./configure
fail
once again, if anybody want's this removed, please say so.
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.
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.
--
Jeff Squyres
Cisco Systems
