Junichi Uekawa wrote:
> In Wed, 10 Jan 2001 18:23:14 -0500 Brian Mays <[EMAIL PROTECTED]> cum
> veritate scripsit :
>
> > [EMAIL PROTECTED] (Junichi Uekawa) wrote:
> >
> > > I think you can actually try playing around with update-alternatives.
> > >
> > > You could build-depend on mpich and lam, and build two versions
> > > playing around with update-alternatives. (theoretically)
> > > Not that I've tried.
> >
> > Hmm ... In my opinion, if you're going to provide libraries built using
> > two different MPI implementations, then you should name the libraries
> > appropriately, so that the user knows which implementation is being
> > used.
> >
> > Therefore, I don't think that alternatives are necessary or are
> > particularly desirable.
>
> No, this comment was about the process of building, not about the
> PetSc library being an "alternatives". I probably didn't make myself
> very clear.
>
> rationale:
>
> In Debian, we only have a Build-Depends: mechanism where we got to install
> both (mpich and lam), or have a separate source tar.gz's (for building
> against mpich
> and lam).
>
> mpich and lam are alternatives, and which can be used to build
> the two versions, and it should work fine with autobuild machines too.
> (it won't work under fakeroot, I believe).
>
> The resulting binary, AFAIK are incompatible.
Right. The other problem is that mpirun takes different arguments for mpich
and lam, and
PETSc comes with a compatibility wrapper script "mpirun.lam" which takes
arguments in mpich
format. Oh- and mpich doesn't have shared libs, so when you link -mpi and
/etc/alternatives points to mpich, there are dangling symlinks for libmpi.so.
:-(
In bmake/linux*/base.site, there are three sets of options for MPI
libraries/commands: one
for mpich, one for lam, and an "agnostic" version which uses commands/libs
linked through
/etc/alternatives. Currently, only the mpich version is uncommented. I
haven't tried the
lam version, but the "agnostic" version failed last time I tried it, because of
the
dangling symlinks.
Any help anyone could provide would be appreciated.
The problem with leaving the agnostic version uncommented is that the version
which builds
depends on what's installed and selected via /etc/alternatives on the
autobuilder! And the
package dependencies won't reflect this because none of the packages ship with
binary
executables, so deps have to be specified in debian/control. Of course, I
could have a
script determine which is installed, and set substvars appropriately to get the
deps right,
but then what to put in Bulid-Depends? And suppose the alpha autobuilder makes
it against
mpich, and the i386 autobuilder against lam? Oh, the support nightmare...
Hmm... On the other hand, I could hardcode mpich and have a bulid-time option
for lam, or
vice versa (depending on Eray's benchmark results). Right now, the package
does one thing
with substvars: because atlas is unavailable on PPC, it depends on
blas/lapack(-dev) on
that platform and atlas on the rest; cxml if you build with Compaq compilers on
Alpha. (I
think that's kinda cool. :-) So it might not take too much more work to allow
the user to
specify something like "debian/rules PETSC_ARCH=linux_alpha_dec MPI_CHOICE=lam
binary"...
I'll consider this for -3.
Oh- and I haven't heard any feedback on removing the version number from the
non-shlibs
packages, so I'll email a couple of other users and remove it if there's no
significant
objection.
Thanks,
-Adam P.
Welcome to the best software in the world today cafe!
