On 12/10/2010, at 1:07 a.m., Scott Brozell wrote:
> My first impression is that this may not be worth the added complexity.
> I'm probably biased since i created AMBERBUILDFLAGS and since it works
> for me. Note that since config.h is a short readable file, one can just
> edit it.
And therein, I think, lies the solution I was looking for. Thanks. In a new round of changes, I'll take out all the CUSTOM stuff, except CUSTOMBUILDFLAGS and AMBERBUILDFLAGS, and those who care can always edit config.h.
I still like the idea of being able to give extra compiler options to Amber code that aren't provided to non-Amber supporting packages, though (for instance, when doing warnings and the like). Also I like the idea of being able to give one set of options to the C compiler and a different set to the Fortran compiler, even if the best way to achieve that is by the builder editing his own config.h.
> Is the FPP set of variables used for C CPP options as well ?
No, but with a bit of re-working it could be. We use the C preprocessor for Fortran code, right?
> Did you eliminate LOCALFLAGS ?
I hadn't hunted for LOCALFLAGS before, but I've just grepped for it, and it may very well be redundant:
[roberts.qtpclnt070 amber-devel]$ grep -r LOCALFLAGS *
AmberTools/src/chamber/Makefile:LOCALFLAGS = $(FREEFORMAT_FLAG)
AmberTools/src/config.h:FFLAGS= -debug all $(LOCALFLAGS) $(CUSTOMFFLAGS)
AmberTools/src/configure:FFLAGS= $fflags \$(LOCALFLAGS) \$(CUSTOMFFLAGS)
AmberTools/src/mopac6/src/Makefile:LOCALFLAGS = -fno-automatic -std=legacy
AmberTools/src/pbsa/Makefile:LOCALFLAGS = $(FREEFORMAT_FLAG)
AmberTools/src/rism/Makefile:LOCALFLAGS = $(FREEFORMAT_FLAG)
AmberTools/src/sqm/Makefile:LOCALFLAGS = $(FREEFORMAT_FLAG)
AmberTools/src/xray/Makefile:LOCALFLAGS = $(FREEFORMAT_FLAG)
src/config.h:FFLAGS= -debug all $(LOCALFLAGS) $(CUSTOMFFLAGS)
src/nmode/Makefile:LOCALFLAGS = $(FREEFORMAT_FLAG)
src/nmr_aux/rotdif/Makefile:LOCALFLAGS = $(FREEFORMAT_FLAG)
src/paramfit/Makefile:LOCALFLAGS =
src/sander/Makefile:LOCALFLAGS = $(FREEFORMAT_FLAG)
[roberts.qtpclnt070 amber-devel]$
I suspect it can therefore be culled as is. But maybe I've overlooked something.
> Does your new setup help handle annoying configure issues, such as,
> mimicking Intel's -fast option ?
It certainly wouldn't hinder them. Very little has changed in the configure script itself, except for a few variable names and some cosmetic changes. In the case of "-fast" in particular, I didn't mess with it since it seems to be used only as a pmemd option; but the man pages have told me what combination of flags could be used in its place (which, for Intel 11, happens to be the same for icc, icpc and ifort). I've put them in configure as a comment.
> As far as gnu make, I'm old school and would prefer vanilla make
> compatibility, but you might be able to convince the powers that be
> that the time is right for gnu make.
As would I.
> Maybe u can commit something to a branch for us to test drive ?
Certainly, once I've tested the changes on my machine.
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Tue Oct 12 2010 - 11:00:02 PDT
