>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: [email protected] Smail: Mail Stop B272 Group HPC-5 Los Alamos National Laboratory Los Alamos, NM 87545 ________________________________________ From: [email protected] [[email protected]] on behalf of Jed Brown [[email protected]] 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 <[email protected]> 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.
