[petsc-dev] Fwd: [ideas-xsdk] common configure/cmake arguments for XSDK packages ready for testing

Matthew Knepley knepley at gmail.com
Thu Dec 25 12:40:33 CST 2014


On Thu, Dec 25, 2014 at 12:35 PM, Satish Balay <balay at mcs.anl.gov> wrote:

> On Wed, 24 Dec 2014, Matthew Knepley wrote:
>
> > On Wed, Dec 24, 2014 at 3:48 PM, Jed Brown <jed at jedbrown.org> wrote:
> >
> > > Barry Smith <bsmith at mcs.anl.gov> writes:
> > >
> > > >> On Dec 24, 2014, at 12:26 PM, Jed Brown <jed at jedbrown.org> wrote:
> > > >>
> > > >> In this case, it might be more reliable to compare "cc --version".
> > > >
> > > >   Presumably this is trivial with the gnumake stuff?
> > >
> > > It's easy to run it and compare before proceeding with the build.
> > >
> > > >   And  the mythical petsc-config could do any number of sanity checks
> > > each time it is run.
> > >
> > > It might be desirable to have a
> > >
> > >   petsc-config verify CC=cc CFLAGS='-m32 -mcmodel=large'
> > > CXXFLAGS=-std=c++11 ...
> > >
> > > that would check whether the given compiler configuration is
> > > binary-compatible with the way PETSc was built.  It should be
> reasonably
> > > fast, but could actually run the compiler.
> > >
> >
> > I of course want these runtime checks. They are the biggest piece missing
> > from the
> > package model.
>
> Hm - most package models [fedora ecosystem or perhaps debian and
> similar] enforce uniform options [compilers, compiler options etc..]
> for all packages in that ecosystem - so such issues don't come up.
>
> And even if petsc were packaged as a 'module' in such a system [say
> cray-petsc] - these issues usually don't come up. I think when
> compiler modules get switched - the petsc libraries (via modules) also
> get switched to the ones compatible with the current compiler..
>

This is exactly the point of view I hate because it does not describe our
experience.
People want the compilers they want, and the packages. The best thing to do
is
check everything at build time so that incompatibilities are caught early.

   Matt


> This issue usually come up when user builds PETSc from source with one
> enviornment - but attempts to use it from a different one..
>
> Satish
>



-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20141225/c34c3795/attachment.html>


More information about the petsc-dev mailing list