On Sun, Jun 16, 2013 at 1:24 PM, Jed Brown <[email protected]> wrote:
> Jack Poulson <[email protected]> writes: > > > > > What is going on with the parmetis CMakeLists.txt? > > > https://bitbucket.org/petsc/pkg-parmetis/src/1c1a9fd0f408dc4d42c57f5c3ee6ace411eb222b/CMakeLists.txt?at=master > > > > It seems to be completely broken. If so, shouldn't it be removed? > > I think CMakeLists.txt was mainly set up for use by > $PETSC_DIR/config/PETSc/packages/parmetis.py, but the modifications seem > to have mainly been to use METIS and GKlib without the hack of > symlinking in the build directory. > > > Am I supposed to be separately checking out pkg-metis if I want to use > > pkg-parmetis? > > No, but it expects METIS to be built (and specified using METIS_PATH; it > looks like a bug in parmetis.py that it can link the wrong libmetis.so). > > > Should we be having this discussion on petsc-dev instead? > > Yes, moving the thread and Cc'ing people who may be interested. > I have been experimenting with having Clique checkout both pkg-metis and pkg-parmetis as part of its build system and it seems that a few things need to be added to the parmetis CMakeLists.txt for it to function correctly (please correct me if I am missing something!). The two main problems are the inclusion of gklib_tls.h and gklib_defs.h, where the former is generated by the metis build system, usually in metis/include in the installation directory, and the latter is is in metis/libmetis/ in the source directory. While setting METIS_PATH to the metis installation directory would pick up gklib_tls.h since ${METIS_PATH}/include is added to the include directories of the parmetis CMakeLists.txt, I do not see any corresponding include_directories statement for the libmetis directory containing gklib_defs.h. Furthermore, I'm not sure if a sufficient number of headers are installed by metis for the parmetis build to succeed if METIS_ROOT is set to the installation directory (but I could be wrong). Jack
