[Octopus-devel] [Octopus-notify] svn commit: r3408 - in trunk: src/basic by xavier
xavier at tddft.org
Thu Oct 25 10:54:03 WEST 2007
Yes, I think it is a good idea to define it like that, but we have to pay
attention to the flags and that actually 'cc -E' behaves the same as 'cpp'.
Perhaps we could look just look for cpp.
Actually this solves a problem with OS X, where the compilation fails
because /lib/cpp doesn't exist (and that is not checked in the configure).
But I think this will not solve the issue with mpi, if you use
--disable-libnbc, you don't need to pass mpi flags to the C compiler. In any
case, the configure script has to be consistent with the code.
On Thu, 25 Oct 2007, Florian Lorenzen wrote:
> Hi Xavier,
> I was thinking about the preprocessor issues a bit: I think, we should
> get away from setting FCCPP to /lib/cpp hardcoded if the user does not
> set FCCPP manually. Instead, we should use CPP which is figured out by
> configure and set to something $(CC) -E or so. Doing so will result in
> mpicc -E for the preprocessing and this wrapper knows where the mpif.h
> file is. (Of course, this does not solve the issue with the stupid SGI
> header, but makes the build more robust in the other cases.)
> What do you think about this?
> octopus-notify at tddft.org writes:
>> Author: xavier
>> Date: Thu Oct 25 09:24:08 2007
>> New Revision: 3408
>> Changeset: http://www.tddft.org/trac/octopus/changeset/3408
>> The header mpif.h is now included directly by the fortran compiler, to
>> avoid problems when FCCPP doesn't know the location of the file and
>> to match the behaviour of the configure script.
>> Doing it this way also solves a problem with SGI MPT mpif.h that has a
>> single ' in the comments that confuses the preprocessor.
>> Octopus-notify mailing list
>> Octopus-notify at tddft.org
More information about the Octopus-devel