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

[Jed Brown]

Jack Poulson <jack.poulson at gmail.com> writes:

> On Fri, Jun 14, 2013 at 9:44 AM, Jack Poulson <jack.poulson at gmail.com>wrote:
>
>> On Fri, Jun 14, 2013 at 2:18 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
>>
>>> Jack Poulson <jack.poulson at gmail.com> 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.

> 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.