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 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120831/d77c352b/attachment.html>
