[petsc-dev] [petsc-maint] Updating PETSc to support Elemental 0.80

[Jack Poulson]

On Mon, Jun 24, 2013 at 11:31 AM, Satish Balay <balay at mcs.anl.gov> wrote:

>
> Looks like parmetis.py is using the cmake option
> '-DGKLIB_PATH=../headers' to set the path to GKlib.h
>
> [I'm not sure if this is prefereable to changing
> pkg-parmetis/CMakeLists.txt as you've indicated]
>
>
Thanks, Satish. I would strongly lean towards having pkg-metis/pkg-parmetis
be a bit more intuitive to build as standalone packages (which is to say, I
think it makes sense to have the include_directories(headers) statement).
It is not obvious that one is expected to:
1) Install metis
2) Set METIS_PATH to the installation directory
3) Set GKLIB_PATH to ./headers


> > Is PETSc using these CMakeLists.txt files? I can now build pkg-parmetis
> on
> > top of a pkg-metis install if I make the above change (and uncomment out
> > lines 9-13 of pkg-parmetis/CMakeLists.txt and actually search for MPI).
>
> Hm - PETSc configure sets up MPI correctly before building
> parmetis. So it should't automatically be searching for MPI.
>
>
A compromise might be to only perform the search if the requisite MPI
variables aren't already defined.

If I am to have Clique build on top of pkg-metis and pkg-parmetis, I will
need to modify them to install enough header files so that it can make use
of metislib.h and parmetislib.h. I'll try to propose a patch over the next
few days and include the 'include_directories(headers)' and replace the
strange 'include(FindMpi); if(NOT MPI_FOUND)' statements with guarded
'find_package(MPI); if(NOT MPI_C_FOUND)' statements.

Jack


> Satish
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130624/6e0fd2bc/attachment.html>