[petsc-dev] get moving on gnu make version of PETSc compiler

Nystrom, William D wdn at lanl.gov
Wed Sep 11 11:58:08 CDT 2013


>From the perspective of PETSc users, what does this mean?  I have a limited understanding
of the PETSc build system right now but am aware that there is the python component, a
cmake component and a legacy component.  There may be other aspects I am not aware
of.  Will there still be the python component?  Is the gmake system replacing cmake?  Will
parallel builds be more robust?  Will the current "all-legacy" target go away or will it be
replaced by whatever gmake is replacing?

Thanks,

Dave

--
Dave Nystrom
LANL HPC-5
Phone: 505-667-7913
Email: wdn at lanl.gov
Smail: Mail Stop B272
       Group HPC-5
       Los Alamos National Laboratory
       Los Alamos, NM 87545


________________________________________
From: petsc-dev-bounces at mcs.anl.gov [petsc-dev-bounces at mcs.anl.gov] on behalf of Jed Brown [jedbrown at mcs.anl.gov]
Sent: Wednesday, September 11, 2013 10:46 AM
To: Satish Balay; Barry Smith
Cc: For users of the development version of PETSc
Subject: Re: [petsc-dev] get moving on gnu make version of PETSc compiler

GNU Make is now the default in 'next'.

Please report any issues.

Satish Balay <balay at mcs.anl.gov> writes:

> From last conversation - we'll have to look at 'shared' targets for
> other arches.

I fixed the Apple shared library suffix issue.

> And figureout a 'user' makefile format that would work with regular
> make as well as exploit gnumake stuff externsions that users might
> want to use..

There is a critical choice of how to deal with changing PETSC_ARCH.  If
you want to build "in-place", we have to do something abusive like
delete object files after compiling, ruining incremental rebuilds.  I
would rather put object files in a "build directory" computed from
PETSC_ARCH.

Complicated packages will always have their own way of organizing
things, so they really only want to get the variables.

I think that namespacing the PETSc makefiles intended for public
inclusion is important, but we can't roll out a change like that until
v3.5.



More information about the petsc-dev mailing list