On Thu, Apr 26, 2012 at 2:36 PM, Kirk, Benjamin (JSC-EG311) <benjamin.kirk-1@nasa.gov> wrote:
>> petsc-dev with trunk libmesh
> Thanks.  I'll see if I can get that build here.
> But I'm betting METIS is the tip of the iceberg - you listed a slew of
> packages on the configure command line that could potentially clash with our
> stuff.
> It may be possible to have libmesh use the petsc metis, but I'm worried that
> could be fragile if, for example, trilinos decided to bundle metis as well.
> I'll see if I can recreate this and work through a solution.

OK, first off I can't get petsc-dev to build for me yet.  Does it *require*
You might need to update the BuildSystem.


Can you try a simple fix though and let me know what this does for you:

At line 336 of your Make.common file, change

libmesh_INCLUDE += -I$(top_srcdir)/contrib/parmetis/Lib


libmesh_INCLUDE += -I$(top_srcdir)/contrib

and then at line 40 of src/partitioning/parmetis_partitioner.C


#     include "parmetis.h"


#     include " parmetis/Lib/parmetis.h"

I've moved this to the -devel to set a bit for discussion.  For things that
we include as contributed packages, but we might reasonably expect  other
people to have, we might consider "prefixing" our includes in the old
C-style?  For background, David is having a parmetis version clash between
ours and the one included in petsc-dev with sieve enabled.


Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Libmesh-devel mailing list