[petsc-dev] clique

[Satish Balay]

The fix I'm hoping for is: the bundled software defaults to using
internal pckage - but the build tools also support
--with-package-include,--with-package-lib options for externally build
version of the internal packages.

this is partly done for metis/parmetis within clique but there is
this other issue with extensions to metis/parmetis we have to fix.

Satish

On Fri, 31 Aug 2012, Jed Brown wrote:

> Jack, this bundling strategy is a distribution nightmare. Suppose that some
> other package "X" independent of clique also bundles Elemental. How does an
> application (or another library) use both X and clique?
> On Aug 31, 2012 1:49 PM, "Satish Balay" <balay at mcs.anl.gov> wrote:
> 
> > Should have cc:d to petsc-dev
> >
> > context:
> >
> > clique packages metis,parmetis,elemental sources in a single bundle.
> > So we were attempting to build them separately [from petsc configure].
> >
> > Jack has extensions to metis and parmetis functionality - thats used
> > in clique. We tried to split this out into separate -lparmetis-addons
> > library [using parmetis public includes] so that our current
> > -lparmetis could be used.  But this doesn't work as it needs parmetis
> > private includes.
> >
> > So looks like we'll have to add these extensions to the metis/parmetis
> > tarballs we distribute [and have common metis/parmetis sources
> > available for both petsc an clique]
> >
> > Satish
> >
> > On Fri, 31 Aug 2012, Satish Balay wrote:
> >
> > > On Fri, 31 Aug 2012, Satish Balay wrote:
> > >
> > > > On Fri, 31 Aug 2012, Jack Poulson wrote:
> > > >
> > > > > > Also does clique also build elemental? Can we split it up aswell
> > with
> > > > > > MANUAL_ELEMENTAL, ELEMENTAL_INCLUDE_DIR, ELEMENTAL_LIBS options?
> > > > > >
> > > > > >
> > > > > I will take care of all of these issues as soon as I get a chance.
> > Clique
> > > > > does currently build Elemental (it sits in external/elemental). If
> > both
> > > > > Clique and Elemental are both to be used in the same package, I
> > would think
> > > > > it would make sense to just install Clique and use its version of
> > > > > Elemental. Is there a problem with this approach? It ensures
> > compatibility.
> > > >
> > > > I'll have to check this - but 2 ways of building the same thing is not
> > > > easy in petsc build tools. Esp when we provide --with-elemental-dir
> > > > option to configure.
> > > >
> > > > Sure we'll have to make sure the compatible elemental,clique are
> > > > installed - when both are installed by petsc [or by user]
> > >
> > > Jack,
> > >
> > > [I'm having to add the flag BUILD_PARMETIS=0.] But now I get:
> > >
> > > cd /home/balay/spetsc/externalpackages/clique/arch-clique/src/parmetis
> > && /usr/lib64/ccache/gcc   -Wall -Wwrite-strings -Wno-strict-aliasing
> > -Wno-unknown-pragmas -g3 -fno-inline -O0
> > -I/home/balay/spetsc/externalpackages/clique/arch-clique/external/elemental/include
> > -I/home/balay/soft/linux64/mpich2-1.1/include
> > -I/home/balay/spetsc/arch-clique/include
> > -I/home/balay/spetsc/externalpackages/clique/external/parmetis/include
> > -I/home/balay/spetsc/externalpackages/clique/external/parmetis/libparmetis
> > -I/home/balay/spetsc/externalpackages/clique/external/parmetis/metis/GKlib
> > -I/home/balay/spetsc/externalpackages/clique/external/parmetis/metis/include
> >    -o CMakeFiles/parmetis-addons.dir/ParallelBisect.c.o   -c
> > /home/balay/spetsc/externalpackages/clique/src/parmetis/ParallelBisect.c
> > >
> > /home/balay/spetsc/externalpackages/clique/src/parmetis/ParallelBisect.c:5:25:
> > fatal error: parmetislib.h: No such file or directory
> > >
> > > Looks like this code needs parmetis private includes. So the current
> > > stratergy [of splitting into -lparmetis-addons] isn't working.
> > >
> > > Perhaps we'll have to use a single patched metis/parmetis tarball for
> > > both petsc and clique afterall..
> > >
> > > Satish
> > >
> >
> >
>