dolfin team mailing list archive

["Matthew Knepley" <knepley@xxxxxxxxx>]

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

I think this argument is strange. It is you who are telling us to use a specific
version of the library. The only reason we ever modify a library is to correct
bugs. Nothing else. If you want the buggy version, go ahead and tell configure
to use it.

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

This argument is outdated. Now petsc-dev will work equally well with shared
and static libraries since we install everything to the prefix.

   Matt

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