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

[Dmitry Karpeev]

On Sat, Jul 9, 2011 at 11:47 AM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>
> On Jul 9, 2011, at 10:41 AM, Jed Brown wrote:
>
>> On Fri, Jul 8, 2011 at 16:48, Barry Smith <bsmith at mcs.anl.gov> wrote:
>>     X    1) Portability to Windows, Cygwin, Unix (all versions)
>>         2) Compatible with GUI development systems (Xcode, Eclipse, Emacs, ...)
>>
>> We can support the systems that we use, but I fear that this task will become endless.
>
>    Sadly we only use Emacs and don't even support that (besides crappy etags) very well.
>
>>
>>         3) Able to run parallel configures and builds (on shared memory system enough?)
>>
>> Probably, distcc can also be used if distributed-memory is needed.
>
>   I think we can steal ideas from distcc but I'd like to keep a pure Python environment.
>
>>
>>         5) Able to handle dependencies between packages (given dependencies between packages builds everything in the correct order)
>>
>> This is important and also quite tricky, especially when dependencies vary based on configuration options.
>>
>> I think we need to be more precise about how to handle packages that depend on PETSc relative to packages that PETSc (optionally) depends on. And how central would PETSc be in this new package management system?
>
>    PETSc should be no different than any other package. It has dependencies on other packages and other packages have dependencies on PETSc (SLEPc, MeshLib,...).  In theory BuildSystem is independent of PETSc but in practice our build infra-structure treats PETSc as a first among equals and that should be changed.

I frequently get this question: I have a code "blah", which has its
own build system (e.g., wmake), and I want to use PETSc solvers in it.
 How can I build the two together?  The usual answer I give that they
either have to (a) build their application using our
makefiles, or (b) include $PETSC_DIR/conf/variables, etc.  This
problem stems from the fact that in the dependency graph we
always treat PETSc as the source and topologically sort from it.  Then
we configure/build the other packages using their own
crappy configure/make systems by feeding them a controlled set of
options. In principle, we could allow PETSc to be an "interior vertex"
so that it is built before some other packages.

Dmitry.

>
>   Barry
>
>
>