On Mon, 24 Jun 2013, Jack Poulson wrote: > On Mon, Jun 24, 2013 at 11:31 AM, Satish Balay <[email protected]> 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.
So clique requires additional include files? I supporse these are private include files from metis/parmetis.. > 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. Looks like that piece of code is from upstream. It has the comment: >> # GK commented this out as it seems to be creating problems << Satish
