dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Sun, Apr 13, 2008 at 08:23:35PM -0500, Matthew Knepley wrote:
> On Sun, Apr 13, 2008 at 2:28 PM, Garth N. Wells <gnw20@xxxxxxxxx> wrote:
> > Matthew Knepley wrote:
> >
> > > I have said this more than 13 times.
> > >
> >
> >  Nice that you're counting ;).
> >
> >
> >  That link procedure is Wrong Wrong Wrong.
> >
> > > I have also given the right ways to do it:
> > >
> > >  1) 'make getlinklibs' prints the correct link line
> > >
> > >  2) 'include ${PETSC_DIR}/conf/variables' in the makefile and use
> > > ${PETSC_TS_LIB}
> > >
> > >  3) Load the pickled configure information and read it into Python.
> > > There is an example
> > >      in $PETSC_DIR/bin/configVars.py
> > >
> > > Why in the hell is this still screwed up? Of course you need to link
> > > all the 3rd party
> > > libraries.
> > >
> > >
> >
> >  There is a reason why we don't want to link to third-party libraries
> >  which PETSc depends on. The reason has been discussed at length on this
> >  list; we don't want to be tied into the libraries (and versions of
> >  libraries) which PETSc downloads and uses, and possibly modifies. Any
> > suggestions on how deal nicely with this issue are welcome.
> 
> The right way to deal with this is to consider each package as an atom. That
> is how we do it in PETSc. If you want to use something like UMFPACK in another
> library, then configure PETSc with that one. Likewise, Dolfin should be
> configured with any libraries downloaded with PETSc. There is no reason that
> this will not work. I do it every day with PyLith and it works fine.
> 
>   Matt

So you suggest that if PETSc needs, downloads and builds package Foo,
then if DOLFIN (or any package that later depends on DOLFIN) should
require to use Foo directly, then DOLFIN must use the Foo built by
PETSc?

That doesn't sound like treating PETSc as an atom, since whatever
PETSc chooses to do will propagate recursively to all things depending
on it.

On the other hand, it's a reasonable assumption, since either
package Foo already available on the system is good. Then PETSc
shouldn't need to download it separately, and everything will work.
On the other hand, if package Foo on the system is not good, then
PETSc shouldn't use it, and neither should we since it's not good.

The conclusion would be to use PETSC_TS_LIB.

Are there any cases where for some reason we really want to use a
different version of a library than PETSc?

-- 
Anders