I agree, that's annoying.
However, is it conceivable that someone may want to install PETSc, download MUMPS, but use their own ParMetis and/or ScaLAPACK (especially the latter, since a vendor-optimized version may already be installed in a system scientific software library, and
that will likely perform better than something that is downloaded and compiled from high-level source)?
I suppose it could be left to the "power users" to specify something like
./configure --download-mumps --with-scalapack=blahblah
and then let the PETSc installer decide on its own that it needs to download ParMetis, but that ScaLAPACK is covered.
At the very least, I would hope that some sort of prominent message is displayed if indeed the PETSc configure automatically decides to download extra things that I didn't specify...
Just my two cents (I'm not a PETSc developer, but I have had lots of experience building PETSc on a wide variety of systems)...
-Tom C.
From: petsc-dev-bounces@mcs.anl.gov [petsc-dev-bounces@mcs.anl.gov] on behalf of Aron Ahmadia [aron.ahmadia@kaust.edu.sa]
Sent: Wednesday, March 21, 2012 5:46 AM
To: For users of the development version of PETSc
Subject: [petsc-dev] --download-dependencies flag?
In order to get a user up-and-running with a MUMPs-enabled PETSc, I followed this frustrating chain:
configure --download-mumps=1
...
Error, no parmetis!
configure --download-mumps=1 --download-parmetis=1
Error, no scalapack!
configure --download-mumps=1 --download-parmetis=1 --download-scalapack=1
It would be convenient if the PETSc BuildSystem did what other package installers like pip, yum, etc..., do, and grab dependencies that I need based on what I have requested.
Additionally, it would make it a lot easier to build PETSc on complicated systems if BuildSystem did a quick dependency/flag check instead off the way it works now (sequential intermixing of really slow and fast configure options).
A