dolfin team mailing list archive

["Matthew Knepley" <knepley@xxxxxxxxx>]

On Mon, Apr 14, 2008 at 12:34 AM, Anders Logg <logg@xxxxxxxxx> wrote:
>
> 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.

You misunderstand what I want. The decisions are:

  1) We want a package Foo

  2) Someone must install Foo

  3) Specify Foo to each package

You can tell PETSc about any package you install by whatever means. Having
PETSc install it is merely another choice for 2. Someone must install Foo.

Ideally, everyone would use the same method for 3, but that is not essential.
And, PETSc does not choose to do anything, its installer does.

>  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.

That is what I would suggest.

   Matt

>  Are there any cases where for some reason we really want to use a
>  different version of a library than PETSc?
>
>  --
>  Anders
>
>
> _______________________________________________
>  DOLFIN-dev mailing list
>  DOLFIN-dev@xxxxxxxxxx
>  http://www.fenics.org/mailman/listinfo/dolfin-dev
>



-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which
their experiments lead.
-- Norbert Wiener