Hi,
On Fri, Oct 08, 2010 at 10:32:36AM -0400, Ben Roberts wrote:
> On 2/9/2010, at 9:45 p.m., Scott Brozell wrote:
> > On Thu, Sep 02, 2010 at 03:29:26PM -0400, Ben Roberts wrote:
> >> On 2/9/2010, at 2:58 a.m., Scott Brozell wrote:
> >>> On Tue, Aug 31, 2010 at 12:13:29PM -0400, Ben Roberts wrote:
> >>>>
> >>>> First, what would people think about a couple of new flags to configure? I was principally thinking, "-debug" and "-warn". These turning on debugging and compiler warnings respectively. At the moment, building a debug version of Amber requires a bit of ad-hockery in config.h, and doesn't affect some components (those with their own configure scripts that are called by configure) at all.
> >>>
> >>> AMBERBUILDFLAGS is suppose to handle that and last time i used it,
> >>> with pgi compilers, it worked:
> >>> 4 drwxr-xr-x 2 xxxx 4096 Jun 6 01:38 pgo0gbin
> >>> E.g.,
> >>> make AMBERBUILDFLAGS='-DDEBUG -Wall -O0 -g'
> >>> does it for gnu.
> >>
> >> There were a couple of problems. One is that AMBERBUILDFLAGS wasn't necessarily observed everywhere, tied as it was to CFLAGS, OCFLAGS, FFLAGS and FOPTFLAGS. I've tried to clean that up a bit.
> >>
> > ok, thanks.
> >
> >> The other is that different compilers have different options. For example, while gcc and gfortran may use the same syntax for enabling warnings and debug symbols, icc and ifort do things a little differently from each other. I can't speak regarding the PGI or Solaris compilers.
> >>
>
> Here's what I've done in my version:
>
> In configure script
> -------------------
>
> $cc, $cxx, $fc = C, C++, Fortran compilers only (I took out flags)
>
> $cflags, $cxxflags, $fflags = compiler flags to be included in all circumstances
>
> $cnooptflags, $cxxnooptflags, $fnooptflags = compiler flags to be included only for code that's not to be optimised
>
> $coptflags (previously $ocflags), $cxxoptflags, $foptflags = compiler flags to be included only for code that is to be optimised
>
> -debug = a switch to enable the debug flags - will add the appropriate switches to $cflags, $cxxflags and $fflags
>
> -noopt = disable optimisation - will ensure that all optflags and nooptflags use -O0 instead of whatever else they'd use
>
> I didn't end up adding a verbose option; I figured that could be done via custom build-time flags (see below).
>
> In config.h (printed by configure script) and Makefiles
> -------------------------------------------------------
>
> CC, CXX, CPLUSPLUS, FC, FPP = compilers and preprocessor
>
> CFLAGS, CXXFLAGS, FFLAGS, FPPFLAGS, LDFLAGS = flags to use in all circumstances
>
> CUSTOMCFLAGS, CUSTOMCXXFLAGS, CUSTOMFFLAGS, CUSTOMFPPFLAGS, CUSTOMLDFLAGS = custom flags (supplied on the "make" line as variables) to use with all programs and libraries - will be added to the above
>
> CUSTOMBUILDFLAGS = supplied on the "make" line as a variable; will be copied into CUSTOMCFLAGS, CUSTOMCXXFLAGS, etc.
>
> AMBERCFLAGS, AMBERCXXFLAGS, AMBERFFLAGS, AMBERFPPFLAGS, AMBERLDFLAGS = custom flags (supplied on the "make" line as variables) to use only with Amber programs. I did this because verbosity options, stricter checking, etc., may not be useful with third-party bits of code that we don't want to mess with.
>
> AMBERBUILDFLAGS = supplied on the "make" line as a variable; will be copied into AMBERCFLAGS, AMBERCXXFLAGS, etc.
>
>
> My concern is that, while this approach gives the developer a good deal of flexibility (and ought to be pretty transparent to the user), it's a bit more complex than the current arrangement.
>
> What do people think? Is this approach one that we'd find helpful?
>
> Currently, the fly in the ointment in my implementation is that I think I've got something in the config.h that's GNU-make specific (viz., the += to append CUSTOMBUILDFLAGS and AMBERBUILDFLAGS to the other variables). I'd feel better if I could use an approach that doesn't demand GNU make and doesn't mess up variable expansion (i.e., "AMBERCFLAGS = $(AMBERCFLAGS) $(AMBERBUILDFLAGS)" would be problematic). Unless everyone uses GNU make these days anyway?
>
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.
Is the FPP set of variables used for C CPP options as well ?
Did you eliminate LOCALFLAGS ?
Does your new setup help handle annoying configure issues, such as,
mimicking Intel's -fast option ?
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.
Maybe u can commit something to a branch for us to test drive ?
scott
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Mon Oct 11 2010 - 22:30:02 PDT
