dolfin team mailing list archive

[johannr@xxxxxxxxx]

On Sat, March 15, 2008 Anders Logg wrote:
> On Sat, Mar 15, 2008 at 12:26:38AM +0100, Åsmund Ødegård wrote:
>> 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!
>
> But <dolfin/main/dolfin.h> is not so nice. It should be enough to do
>
> #include <dolfin.h>
>
>> >  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!
>
> ok!

Should be fixed now!

Johannes

> --
> Anders
>
>
>>
>> >
>> >
>> >  > >  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
>> _______________________________________________
>> DOLFIN-dev mailing list
>> DOLFIN-dev@xxxxxxxxxx
>> http://www.fenics.org/mailman/listinfo/dolfin-dev
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev
>