On Sun, 1 Mar 2020, Alexander Lindsay wrote: > Is it safe to assume that mpicxx will always add the requisite include and > library flags?
Yes. There are always broken compilers. Similarly - there can always be broken mpi compilers aswell. > Are there any/many implementations that do not take the -show flag? For ex: cray. [they don't have 'mpicc', and no 'mpicc -show' or 'cc -show' ] Satish > > > On Feb 27, 2020, at 7:15 PM, Satish Balay <[email protected]> wrote: > > > > Not really useful for autotools - but we print the mpi.h used during > > build in make.log > > > > Using mpi.h: # 1 "/home/petsc/soft/mpich-3.3b1/include/mpi.h" 1 > > > > I guess the same code [using a petsc makefile] - can be scripted and > > parsed to get the PATH to compare in autotools. > > > > However the current version check [below] is likely the best way. Our > > prior check was deemed too strict - for ex: when linux distros updated > > MPI packages with a bug fixed version [without API change] - our prior > > check flagged this as incompatible - so we had to change it. > > > > Satish > > > >> On Thu, 27 Feb 2020, Jed Brown wrote: > >> > >> If determining mpicc is sufficient, this will work > >> > >> pkg-config --var=ccompiler PETSc > >> > >> We also define > >> > >> $ grep NUMVERSION mpich-optg/include/petscconf.h > >> #define PETSC_HAVE_MPICH_NUMVERSION 30302300 > >> > >> or > >> > >> $ grep OMPI_ ompi-optg/include/petscconf.h > >> #define PETSC_HAVE_OMPI_MAJOR_VERSION 4 > >> #define PETSC_HAVE_OMPI_MINOR_VERSION 0 > >> #define PETSC_HAVE_OMPI_RELEASE_VERSION 2 > >> > >> which PETSc uses to raise a compile-time error if it believes you're > >> compiling PETSc code using an incompatible MPI. > >> > >> Note that some of this is hidden in the environment on Cray systems, for > >> example, where CC=cc regardless of what compiler you're actually using. > >> > >> Alexander Lindsay <[email protected]> writes: > >> > >>> What's the cleanest way to determine the MPI install used to build PETSc? > >>> We are configuring a an MPI-based C++ library with autotools that will > >>> eventually be used by libMesh, and we'd like to make sure that this > >>> library > >>> (as well as libMesh) uses the same MPI that PETSc used or at worst detect > >>> our own and then error/warn the user if its an MPI that differs from the > >>> one used to build PETc. It seems like the only path info that shows up is > >>> in MPICXX_SHOW, PETSC_EXTERNAL_LIB_BASIC, and PETSC_WITH_EXTERNAL_LIB (I'm > >>> looking in petscvariables). I'm willing to learn the m4/portable shell > >>> built-ins necessary to parse those variables and come out with an mpi-dir, > >>> but before doing that figured I'd ask here and see if I'm missing > >>> something > >>> easier. > >>> > >>> Alex > >> > > >
