[mpich2-dev] CFLAGS ordering in mpicc

[Anthony Chan]

----- "Joe Ratterman" <jratt at us.ibm.com> wrote:

> One of the requirements of the layout change was that all code that
> used to compile still compiles without changes.
> 
>     • Without the -I...., people who use other headers may get errors.
>     • With the -I...., people who use those other headers in new
> locations may get errors.

all sys/include and comm/include were used to be in comm/include, so
mpixlc could be used to compile non-MPI dcmf or spi program.  
Are there anyone who actually use mpixlc to compile non-MPI dcmf/spi programs ?
I would think those users should have been using bgxlc directly, right ?

> What errors exactly could happen in mpif77?

Some compilers (not on BG) may complain or fail if CFLAGS or FFLAGS
are swappered with $allargs.

A.Chan
> 
> 
> Thanks,
> Joe Ratterman
> jratt at us.ibm.com
> 
> 
> 
> On Wed, Jun 25, 2008 at 12:05 PM, Anthony Chan < chan at mcs.anl.gov >
> wrote:
> 
> 
> Hi Joe,
> 
> The problem here is that you used CFLAGS to set dcmf/spi include
> directory when configuring
> MPICH2. mpicc and friends generated by configure has this line during
> linking/compiling( as you've pointed out)
> 
> 
> $Show $CC $CFLAGS $allargs -I$includedir
> 
> user's include path will be in $allargs. This causes a problem because
> dcmf/spi
> is in CFLAGS before user's. Swapping $CFLAGS and $allargs in mpicc.in
> and friends
> could solve the problem, but then it may cause portability issue for
> MPICH2 on other
> platforms(especially with mpif77/mpif90....). I wonder if you could
> use MPICH2LIB_CFLAGS
> and friends to point to dcmf/spi headers when configuring MPICH2 with
> dcmfd. That way mpicc and friends won't have
> -I/bgsys/drivers/ppcfloor/comm/sys/include. If users want to include
> dcmf/spi
> headers with mpicc and friends, they could include the headers
> explicitly. Main thing here
> is that mpicc (mpixlc in your case) are for compiling MPI programs, so
> i would naively think
> you don't need -I/bgsys/drivers/ppcfloor/comm/sys/include unless your
> mpi.h contains references
> to dcmf/spi symbols....
> 
> PS. The user that you refered to could be me....
> 
> A.Chan
> 
> 
> 
> 
> ----- "Joe Ratterman" < jratt at us.ibm.com > wrote:
> 
> > We are looking at a problem reported by a user. We recently moved
> some
> > files around in our system. Previously, various communication
> include
> > files were located in the same dir as the MPI header files. This was
> > simple for the users, but for various reasons they have been moved
> > into another area, which we added to the WRAPPER_CFLAGS var via the
> > CFLAGS var at configure time.
> >
> > It seems that the user is having difficulty over-riding the built-in
> > helper directory. For example:
> >
> > mpicc -show -I/11111111111 -c foo.c -I/2222222222
> > cc -I/bgsys/drivers/ppcfloor/comm/sys/include -I/11111111111 -c
> foo.c
> > -I/2222222222 -I/bgsys/drivers/ppcfloor/comm/include
> > MPI Files : /bgsys/drivers/ppcfloor/comm/include
> > Other comm includes (that the user hopes to over-ride) :
> > /bgsys/drivers/ppcfloor/comm/sys/include
> >
> > The following are the interesting lines in the mpicc file
> >
> > prefix=/bgsys/drivers/ppcfloor/comm
> > includedir=${prefix}/include
> > WRAPPER_CFLAGS="-I/bgsys/drivers/ppcfloor/comm/sys/include"
> > CFLAGS="$WRAPPER_CFLAGS"
> > $Show $CC $CFLAGS "${allargs[@]}" -I$includedir
> >
> > It doesn't really seem correct (in this case anyway) to have CFLAGS
> > ahead of the user args. Is there a specific reason that I am
> missing?
> > Is it something that should be changed?
> > MPICH2 Version 1.0.7
> >
> >
> > Thanks,
> > Joe Ratterman
> > jratt at us.ibm.com