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

[Satish Balay]

On Thu, 25 Dec 2014, Matthew Knepley wrote:

> 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.


Sure - different folks (petsc users) have different requirements that
we would have to support - but thats a bit different than saying the
packaging model has to support this.. [and shound't be a -ve for
supporting distribution of PETSc via any of the packaging echo
systems - in addition to supporting source distribution]

Satish

> 
>    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
> >
> 
> 
> 
>