[petsc-dev] new configuration/compile system for PETSc

[Dmitry Karpeev]

When you say "Portability to Windows", do you mean "native Windows,
without Cygwin"?
I agree that cmake is less than cool.

Suppose there is a package we need already installed on the system
(e.g., hdf5 installed in <hdf5_dir>),
which depends on another package we need, which is also already
installed on the system (e.g., openmpi_dir, installed in
<openmpi_dir>).  The user requests --with-hdf5-dir=<hdf5_dir>
--download-mpich.
Is this dangerous? Can/should we be able to detect this?

On the system where I encountered this (Ubuntu), there is a package
management system (apt-get) that contains the necessary information,
but I think it would be prohibitively complex to make PETSc configure
compatible with all package management systems so we can parse their
package databases.

As a related matter, there is a sometimes unclear distinction between
a package (e.g., mpich or openmpi) and an abstract "capability"
(mpi), which can be satisfied by multiple packages (openmpi, mpich).
We have both: --with-mpi-dir=<mpi_dir> (capability),
--download-mpich=1 (package).  This is, of course, due to the fact
that the "capability" has a standard interface (the MPI standard),
that multiple packages can satisfy. If FFT had a similar standardized
interface we could potentially have the same ambiguity with fft and
fftw.  BLAS-LAPACK may be another such example.

Dmitry.

On Fri, Jul 8, 2011 at 4:48 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>
>   I am revisiting the idea of a new configuration/compile system for PETSc (with the prototype cll:  ssh://petsc@petsc.cs.iit.edu//hg/petsc/cll) and am currently trying to see if we can come up with a list of requirements that satisfies all our needs and everyone's ambitions.  I have added a preliminary list at the top of the cll.py file in that repository and also posted here.
>
> Requirements:
>     X    1) Portability to Windows, Cygwin, Unix (all versions)
>         2) Compatible with GUI development systems (Xcode, Eclipse, Emacs, ...)
>         3) Able to run parallel configures and builds (on shared memory system enough?)
>         4) Able to work with batch systems
>         5) Able to handle dependencies between packages (given dependencies between packages builds everything in the correct order)
>         6) Able to utilize clang and similar systems
>         7) Works seamlessly with GNU autoconf and Cmake packages (that is will build these packages automatically)
>         8) Can download and install packages by given URL
>         9) Easy to add configurations for packages such as SuperLU, etc that have no decent configuration
>     x   10) Can test for available functionalities (include files, etc)
>     X   11) Easy to add new types of compilers, new tests
>        12) Does dependency analysis and rebuilds only what needs to be rebuilt
>        13) Able to manage test suites
>        14) Compatible with and able to use revision control systems
>        15) Completely command-line controlled but also with a GUI frontend that gives one full control as well
>        16) Able to build for bizarre-assed systems like the iPAD and GPUs.
>
>    X  - does,   x - does some
>
> I looked at cmake recently and was not pleased with what I saw.
>
> Any comments, thoughts, complaints and volunteers early solicited.
>
>    Barry
>
>