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.
