I seemed to have ignored your question. If compatible versions of the library are used in package "X", then everything should work fine. Is there a problem which you are expecting? I recognize that there is a potential issue of a newer version of Elemental or Clique conflicting with an older version, but surely you guys are willing to deal with external libraries also changing their syntax from time to time... Jack On Fri, Aug 31, 2012 at 2:28 PM, Jed Brown <[email protected]> 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" <[email protected]> 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
participants (1)
-
Jack Poulson