On Thu, 25 Dec 2014, Matthew Knepley wrote: > On Thu, Dec 25, 2014 at 12:35 PM, Satish Balay <[email protected]> wrote: > > > On Wed, 24 Dec 2014, Matthew Knepley wrote: > > > > > On Wed, Dec 24, 2014 at 3:48 PM, Jed Brown <[email protected]> wrote: > > > > > > > Barry Smith <[email protected]> writes: > > > > > > > > >> On Dec 24, 2014, at 12:26 PM, Jed Brown <[email protected]> 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 > > > > > >
