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

[Dmitry Karpeev]

Observe that PETSc's configure deals with the problem of consistently
configuring MULTIPLE
packages, while most tools I have heard of typically deal with a
SINGLE package.  That's a
qualitative difference, in my opinion.

Separately, I would suggest having the new build system allow the user
to install PETSc in one
go.  Something like 'cll install --with-clanguage=c++ ...', because
it's rare for users to stop after
configuring, and then end up executing an easily automatable sequence of steps:
configure --with-clanguage=c++ ...
make PETSC_DIR= ... all
make PETSC_DIR= ... PETSC_ARCH=... test

Of course, we should provide intermediate stages as well -- 'cll
configure' -- etc.
In particular, if cll were able to configure "arbitrary" collections
of packages, it may be desirable
to leave the "top" package configured, but not built, as it has to be
built repeatedly (as part of
a development cycle) using make or cmake, etc.

Dmitry.

On Sat, Jul 9, 2011 at 7:37 PM, Dmitry Karpeev <karpeev at mcs.anl.gov> wrote:
> On Sat, Jul 9, 2011 at 7:18 PM, Harald Pfeiffer
> <pfeiffer at cita.utoronto.ca> wrote:
>> We happen to use Petsc with our own makefiles.  PETSc is compiled entirely
>> separately (or we use system-provided PETSc-modules).   We then manually set
>> the appropriate include- and library-paths in our makefiles, for example:
>>
>> PETSC_INCLUDE = -I$(PETSC_DIR)/include -I$(PETSC_DIR)/$(PETSC_ARCH)/include
>> PETSC_LIB = -L$(PETSC_DIR)/$(PETSC_ARCH)/lib -lpetsc -lX11
>> ...
>> other stuff here
>> ...
>> ARCH_INCLUDE = $(PETSC_INCLUDE)  ...
>> ARCH_LIB_PARALLEL   = $(HDF_LIB) $(FFTW_LIB) $(PETSC_LIB)  ....
>>
>>
>> Not elegant, but has been working like a charm for the last 12 years.
>
> I'm not saying it can't be made to work.
> I'm saying it might not be trivial for someone just starting to use
> PETSc and not even necessarily
> that familiar with make: there are a lot of potential users like that.
>  And even for more sophisticated
> users it might take a while to work out the kinks.
>
> Dmitry.
>
>>
>>
>> Harald
>>
>>
>>
>>
>>
>>
>> On 7/10/11 1:02 AM, Dmitry Karpeev wrote:
>>>
>>> On Sat, Jul 9, 2011 at 6:42 PM, Jed Brown<jedbrown at mcs.anl.gov>  wrote:
>>>>
>>>> On Sat, Jul 9, 2011 at 18:30, Dmitry Karpeev<karpeev at mcs.anl.gov>  wrote:
>>>>>
>>>>>  If a user could write a
>>>>> simple foo.py that configured/built their
>>>>> favorite package with PETSc as a dependency, they could then proceed
>>>>> to modify the FOO code and jack
>>>>> PETSc into it.
>>>>
>>>> But this just a different form of asking them to adopt our build system,
>>>> except that makefiles are a de-facto standard and our system won't be
>>>> familiar to anyone. Any system has to be easily usable from other systems
>>>> (at least makefiles, automake, and cmake).
>>>
>>> Yes, but there is also a practical problem: an engineer or a scientist,
>>> not
>>> intimately familiar with automake, cmake, etc., has taken the effort
>>> to understand
>>> PETSc so that our linear solvers can be substituted for FOO's.  How can we
>>> make it easier for these people to insert PETSc into their code?  Here
>>> I only mean
>>> the build process.  Maybe making them write foo.py is not the right
>>> approach,
>>> but we should have a usable approach (and, maybe, an example of doing it).
>>>
>>> In particular, is it sufficient to export linklibs, or do we also need
>>> to export the
>>> compiler (e.g., to ensure consistent Fortrant name mangling)?  There are
>>> a good number of Fortran users that want to use PETSc too.
>>>
>>> Dmitry.
>>
>> --
>> Harald Pfeiffer
>> Assistant Professor
>> Cdn. Institute for Theoretical Astrophysics
>> University of Toronto
>> pfeiffer at cita.utoronto.ca
>> Tel. ++1 416-978-8497
>>
>>
>