dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Apr 14, 2008 at 07:42:35AM +0100, Garth N. Wells wrote:
> 
> 
> Anders Logg 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.
> > 
> > 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.
> >
> 
> PETSc often uses modified versions of libraries and/or versions that are 
> not the latest release. A case in point is UMFPACK. It's not just a 
> question of good and not good.

ok, thanks for clarifying.

> > 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?
> > 
> 
> I don't want to be locked into outdated or modified libraries. We should 
> decide which libraries we want to use and not let PETSc make this 
> determination. I let PETSc download external packages when the precise 
> version is important for PETSc, or they've been modified. Since these 
> are specific to PETSc, the PETSc libaries should know where they are. I 
> never do it with the intention to use the libraries system wide. If 
> PETSc is configured to use shared libraries, it knows where everything 
> is. If PETSc is configured to use static PETSc libaries, it doesn't. I 
> see this as a flaw in the PETSc build system.

Or rather an issue which is difficult to get around when using static
libraries since there is no obvious mechanism to set the dependencies.

So then the conclusion must be: build PETSc using --with-shared=1 or else
it won't work and there is no way for us to fix it.

-- 
Anders

> On top of all this, letting PETSc decide the libraries will complicate 
> our build system and I can imagine that packaging will be more difficult.