dolfin team mailing list archive

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

On Sat, Mar 15, 2008 at 12:21 AM, Anders Logg <logg@xxxxxxxxx> wrote:
>
> On Sat, Mar 15, 2008 at 12:00:35AM +0100, Åsmund Ødegård wrote:
>  > 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).
>
>  That's not so good. One major point with the demos is that it should
>  be possible to copy them elsewhere and still compile them.

What's the problem? <dolfin/main/dolfin.h> will work both installed
and in the source-dir!

>  If this is tricky to solve with the build system, we could require
>  that DOLFIN be installed before the demos can be built. That's how we
>  did it before.

We should be able to do better! Putting dolfin.h directly in dolfin as
you suggested, and confirmed working by Ilmar, seems to be a nice
alternative - if the option above still has issues. I guess Johannes
can work this out on monday!


>
>
>  > >  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...
>
>  Sounds just as bad... :-)

Agree!


Åsmund