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

[Barry Smith]

On Jul 8, 2011, at 6:34 PM, Dmitry Karpeev wrote:

> When you say "Portability to Windows", do you mean "native Windows,
> without Cygwin"?

   Yes, cll does this and I submit this is actually not difficult (some other requirements may be :-(

> I agree that cmake is less than cool.
> 

    These are good points. I've added them to the master list in cll.py

    Now that we've started a list it would be a good idea to start adding thoughts on how each requirement could be met in a clean way.

    Barry

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