Jed Brown writes: > Jack Poulson <[email protected]> writes: > >> On Fri, Jun 14, 2013 at 9:44 AM, Jack Poulson <[email protected]>wrote: >> >>> On Fri, Jun 14, 2013 at 2:18 AM, Jed Brown <[email protected]> wrote: >>> >>>> Jack Poulson <[email protected]> writes: >>>> > By the way, was any decision made on having an repository for the PETSc >>>> > modifications of (Par)Metis? >>>> >>>> https://bitbucket.org/petsc/pkg-parmetis/ >>>> >>>> I can give you access to this repository if you want to get a branch >>>> going. Note that it has been modified to de-bundle metis and gklib, so >>>> that we can combine binary libA that links against libmetis with libB >>>> that links against libparmetis. >>>> >>> >>> Thanks. That would help. Hopefully I can do this relatively soon. >>> >>> Jack >>> >> >> 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.
That's right. I initially wanted to rip out all the hacks and make metis and parmetis both installable from a package managers point-of-view. >> 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). There might be other bugs in my amateur's attempt at writing cmake but Jed is right that my design was to make parmetis dependent on metis (why duplicate code and conflate linking packages?).
