dolfin team mailing list archive

["Åsmund Ødegård" <aasmund@xxxxxxxxx>]

On Sun, Mar 16, 2008 at 11:21 PM, Matthew Knepley <knepley@xxxxxxxxx> wrote:
>
> On Sun, Mar 16, 2008 at 5:18 PM, Åsmund Ødegård <aasmund@xxxxxxxxx> wrote:
>  > On Sun, Mar 16, 2008 at 10:44 PM, Matthew Knepley <knepley@xxxxxxxxx> wrote:
>  >  > >  This is the behavior I observed, although it was more than a year ago
>  >  >  >  that I put a line in my makefile to determine if mpicxx existed in the
>  >  >  >  same path, and if not, try to use the mpicc (provided by PCC_LINKER) as
>  >  >  >  a C++ compiler.  I generally use openmpi, but often build PETSc
>  >  >  >  with-clanguage=C since I don't use the C++ interface (I'm playing with
>  >  >  >  sieve now so this has changed).  Then PCC_LINKER would give me a C
>  >  >  >  compiler (mpicc) and I would look for a C++ compiler at the same path
>  >  >  >  (since the code I was compiling was C++).  This worked great for me, but
>  >  >  >  it broke for some people who had PETSc install mpich2.  The problem was
>  >  >  >  that mpicc was actually a C++ compiler and there was no mpicxx at that
>  >  >  >  path.  It would have been a PETSc configured with-clanguage=C++.  In
>  >  >  >  trying to reproduce this with a recent PETSc (2.3.3-p6 and petsc-dev) it
>  >  >  >  looks like mpich2 produces just mpicc (which is not a C++ compiler) when
>  >  >  >  configured with-clanguage=C and correctly produces mpicxx when
>  >  >  >  with-clanguage=C++.  This is entirely sane behavior.  I'm not sure why
>  >  >  >  Osman is seeing the former behavior even with a recent PETSc.
>  >  >
>  >  >  Yes, if C++ is not turned on in PETSc, we will not generate an mpicxx when
>  >  >  installing MPICH2. For the C compiler, we take whatever is specified
>  >  >  using --with-cc
>  >  >  or the one we find by default if nothing is specified. You can see which one we
>  >  >  found using mpicc --show.
>  >  >
>  >
>  >  This make kind of sense, of course. But it also makes it a bit hard,
>  >  as Petsc tend to be quite picky about compilers. Dolfin is C++, so
>  >  some mpicxx is needed when Dolfin and Petsc are linked together. Maybe
>  >  the best solution is to skip the wrappers altogether, just extract
>  >  what we need from mpicc -show, and build the correct commands.
>
>  I really really would not do this. It will cause future pain. I used to do that
>  and gave up. The right thing to do is to actually ask for what you wany,
>  --with-clanguage=c++ when building PETSc since you do in fact need C++.
>  Then everything will work fine.

Sure - but that requires people to think.... I mean, they have to
decide when they are building PETSc that they later on like to link
Dolfin with PETSc. Or rebuild PETSc when building Dolfin (not PETSc by
the way, only the mpich2 built by PETSc....).

But you have a good point, for now we can just skip the PETSc
dependency for Dolfin if the mpicxx is not around, and give a nice
message to the user about it (maybe even include something about the
--with-clanguage option).


Åsmund