<div dir="ltr"><div dir="ltr">On Sun, Mar 1, 2020 at 2:43 PM Alexander Lindsay <<a href="mailto:alexlindsay239@gmail.com">alexlindsay239@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Is it safe to assume that mpicxx will always add the requisite include and library flags?</blockquote><div><br></div><div>Yes, that is the contract.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Are there any/many implementations that do not take the -show flag?<br></blockquote><div><br></div><div>I thought only MPICH took that flag.</div><div><br></div><div>  Thanks,</div><div><br></div><div>     Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> On Feb 27, 2020, at 7:15 PM, Satish Balay <<a href="mailto:balay@mcs.anl.gov" target="_blank">balay@mcs.anl.gov</a>> wrote:<br>
> <br>
> Not really useful for autotools - but we print the mpi.h used during<br>
> build in make.log<br>
> <br>
> Using mpi.h: # 1 "/home/petsc/soft/mpich-3.3b1/include/mpi.h" 1<br>
> <br>
> I guess the same code [using a petsc makefile] - can be scripted and<br>
> parsed to get the PATH to compare in autotools.<br>
> <br>
> However the current version check [below] is likely the best way. Our<br>
> prior check was deemed too strict - for ex: when linux distros updated<br>
> MPI packages with a bug fixed version [without API change] - our prior<br>
> check flagged this as incompatible - so we had to change it.<br>
> <br>
> Satish<br>
> <br>
>> On Thu, 27 Feb 2020, Jed Brown wrote:<br>
>> <br>
>> If determining mpicc is sufficient, this will work<br>
>> <br>
>>  pkg-config --var=ccompiler PETSc<br>
>> <br>
>> We also define<br>
>> <br>
>> $ grep NUMVERSION mpich-optg/include/petscconf.h <br>
>> #define PETSC_HAVE_MPICH_NUMVERSION 30302300<br>
>> <br>
>> or<br>
>> <br>
>> $ grep OMPI_ ompi-optg/include/petscconf.h <br>
>> #define PETSC_HAVE_OMPI_MAJOR_VERSION 4<br>
>> #define PETSC_HAVE_OMPI_MINOR_VERSION 0<br>
>> #define PETSC_HAVE_OMPI_RELEASE_VERSION 2<br>
>> <br>
>> which PETSc uses to raise a compile-time error if it believes you're<br>
>> compiling PETSc code using an incompatible MPI.<br>
>> <br>
>> Note that some of this is hidden in the environment on Cray systems, for<br>
>> example, where CC=cc regardless of what compiler you're actually using.<br>
>> <br>
>> Alexander Lindsay <<a href="mailto:alexlindsay239@gmail.com" target="_blank">alexlindsay239@gmail.com</a>> writes:<br>
>> <br>
>>> What's the cleanest way to determine the MPI install used to build PETSc?<br>
>>> We are configuring a an MPI-based C++ library with autotools  that will<br>
>>> eventually be used by libMesh, and we'd like to make sure that this library<br>
>>> (as well as libMesh) uses the same MPI that PETSc used or at worst detect<br>
>>> our own and then error/warn the user if its an MPI that differs from the<br>
>>> one used to build PETc. It seems like the only path info that shows up is<br>
>>> in MPICXX_SHOW, PETSC_EXTERNAL_LIB_BASIC, and PETSC_WITH_EXTERNAL_LIB (I'm<br>
>>> looking in petscvariables). I'm willing to learn the m4/portable shell<br>
>>> built-ins necessary to parse those variables and come out with an mpi-dir,<br>
>>> but before doing that figured I'd ask here and see if I'm missing something<br>
>>> easier.<br>
>>> <br>
>>> Alex<br>
>> <br>
> <br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>