dolfin team mailing list archive

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

On Fri, Mar 14, 2008 at 11:49 PM, Anders Logg <logg@xxxxxxxxx> wrote:
>
> On Fri, Mar 14, 2008 at 11:11:54PM +0100, Åsmund Ødegård wrote:
>  > On Fri, Mar 14, 2008 at 11:04 PM, Anders Logg <logg@xxxxxxxxx> wrote:
>  > >
>  > > On Fri, Mar 14, 2008 at 07:04:40PM +0100, Ilmar Wilbers wrote:
>  > >  > I spent hours today debugging a problem I kept getting when compiling
>  > >  > dolfin with petsc (and openmpi) on my Macbook (really, the demos):
>  > >  > /usr/local/include/petscmath.h:16: error: 'MPI_Datatype' does not name a
>  > >  > type
>  > >  > /usr/local/include/petscmath.h:17: error: 'MPI_Datatype' does not name a
>  > >  > type
>  > >  > /usr/local/include/petscmath.h:294: error: 'MPI_Comm' has not been declared
>  > >  > /usr/local/include/petscmath.h:295: error: 'MPI_Comm' has not been declared
>  > >  > /usr/local/include/petscmath.h:296: error: 'MPI_Comm' has not been declared
>  > >  > /usr/local/include/petsc.h:451: error: 'MPI_Comm' does not name a type
>  > >  > /usr/local/include/petsc.h:469: error: expected primary-expression
>  > >  > before '(' token
>  > >  > [...]
>  > >  > /usr/local/include/petscksp.h:528: error: initializer expression list
>  > >  > treated as compound expression
>  > >  > scons: *** [demo/fem/assembly/cpp/main.o] Error 1
>  > >  > scons: building terminated because of errors.
>  > >  >
>  > >  > I dug deep down in petsc internals, its includes, dependencies etc. At
>  > >  > last I found the error, but it had nothing to do with petsc or MPI.
>  > >  > Someone had checked in the file MPI.h in dolfin/main. OSX is, just as
>  > >  > Windows, case-insensitive (except Åsmunds machine, as he made it
>  > >  > case-sensitive). Because petsc.h includes mpi.h, and the flag
>  > >  > -I/dolfin/main is present as well as -I/usr/include, petsc tried to
>  > >  > include the file dolfin/main/MPI.h, which certainly does not have all
>  > >  > the declarations as /usr/include/mpi.h
>  > >  >
>  > >  > This problem will affect all Mac and Window users. I don't know where
>  > >  > the file MPI.h is included, but simply renaming it worked for me. Can
>  > >  > the right person (Garth, I saw your name in the file?) rename the file
>  > >  > and all places it is used?
>  > >  >
>  > >  > I guess the conclusion is that we should avoid all file names that,
>  > >  > regardless of case, might be used elsewhere.
>  > >
>  > >  I'm not so sure. It would be very difficult if we had to look at all
>  > >  other systems when choosing our file names. We have several files that
>  > >  are likely to appear elsewhere: init,h, constants.h, basic.h, File.h
>  > >  etc. The important thing should be that we define everything under
>  > >  our own namespace dolfin:: and install everything under $prefix/dolfin.
>  > >
>  > >  Why does the build system pick up MPI.h from DOLFIN? MPI.h should only
>  > >  be available as <dolfin/main/MPI.h> and this is unlikely to appear in
>  > >  PETSc.
>  > >
>  >
>  > He is building dolfin demos, remember. And have enabled petsc. In some
>  > petsc file there is a #include "mpi.h" (not very strange) - but
>  > dolfin/main/MPI.h is selected as -I.../dolfin/include comes first on
>  > the mpicxx line.
>  >
>  > See?
>
>  No. If it was just -I.../dolfin/include then everything should be fine
>  since MPI.h is not in that directory. But when I compile the demos, I
>  see something else that might be the problem:
>
>   -Idolfin/main
>
>  I guess this is because dolfin.h is in that directory, and then MPI.h
>  happens to be in the same directory...

Good point. But dolfin.h is also located in the toplevel include when
installed. So this is a problem only when building demos against
not-installed dolfin... The -Idolfin/main should not be there IMHO...
Could the demos just use #include <dolfin/main/dolfin.h> instead (if
they should work before scons install).

>
>  Maybe we should just move dolfin.h to dolfin (src)? That should take
>  care of it.

Maybe that's an option. I think must be moved all the way to the top
level though.

>
>  And maybe we should also rename the main directory to something else,
>  but I can't figure out what. It's sort of a mix of things that doesn't
>  fit in anywhere else.


main is probably not the best name, but it is hard to come up with
good alternatives. Pycc use kernel for somewhat similar things...

Åsmund