Re: PetSc

[Adam C Powell IV <hazelsct@mit.edu>]

Junichi Uekawa wrote:

> In Wed, 10 Jan 2001 18:23:14 -0500 Brian Mays <brian@debian.org> cum veritate scripsit :
>
> > dancer@netfort.gr.jp (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!