On Sat, Jul 18, 2009 at 3:22 PM, Mike Frysinger<[email protected]> wrote: > On Saturday 18 July 2009 17:25:58 Garrett Cooper wrote: >> On Wed, Jul 15, 2009 at 9:37 AM, Mike Frysinger<[email protected]> wrote: >> > On Sunday 12 July 2009 01:49:52 Garrett Cooper wrote: >> >> +# Avoid overwriting definitions in leaf callers. >> >> +CPPFLAGS ?= @CPPFLAGS@ -I$(includedir) >> >> +CFLAGS ?= @CFLAGS@ >> >> +LDLIBS ?= @LIBS@ >> >> +LDFLAGS ?= @LDFLAGS@ -L$(libdir) >> > >> > this looks like it'll cause problems if you set these in your environment >> > export CPPFLAGS='' CFLAGS='-pipe' LDFLAGS='' >> > make >> > >> > i would use $(origin ...) to determine whether the variables are coming >> > from the leaf Makefile >> >> Ah, yes. Excellent point. >> >> So what's the appropriate protocol then: >> >> If set in environment, ignore? >> Or: >> If set in Makefile, ignore? > > if it's set in the env, the "?=" should already handle that. i cant think of > a reason for the leaf makefiles to be settings default flags ... do you have > an example in mind ?
Yes, actually. The problem with the current system is that we keep on using +=, which bloats the CFLAGS / LDFLAGS / LDLIBS, etc unnecessarily, so if we get 5 levels deep we end up with a line like: gcc -I../../../../../include -I../../../../include -I../../../include -I../../include -I../include etc. Now that's just plain silly and we'll run into ceilings very quickly with long argument lines, plus it'll slow down gcc / binutils with the search path. >> >> +DEBUG_CFLAGS ?= -g >> >> +DEBUG_CXXFLAGS ?= $(DEBUG_CFLAGS) >> >> + >> >> +CFLAGS += $(DEBUG_CFLAGS) >> >> +CXXFLAGS += $(DEBUG_CXXFLAGS) >> >> + >> >> +# There have been several bugs in the past related to -O2+ when >> >> +# -fno-strict-aliasing is not specified. >> >> +OPT_CFLAGS ?= -O2 -fno-strict-aliasing >> >> +OPT_CXXFLAGS ?= $(OPT_CFLAGS) >> > >> > in general, i recall only like 1 bug that was a gcc issue. all the >> > others were broken source code. i dont think we should live with code >> > that violates aliasing rules. >> >> See my previous comment. There are ~10 different bugs spanning >> compilers from v3.3.x to 4.4.x, which deal with broken >> -fstrict-aliasing optimizations in the tree optimizer. > > please centralize the comments then rather than sprinkling them about the > different source files. here the comment should say: > # -fno-strict-aliasing: please see README.mk-devel Will do. >> >> --- m4/GNUmakefile 18 Jan 2009 22:22:40 -0000 1.1 >> >> +++ m4/GNUmakefile 12 Jul 2009 05:46:28 -0000 >> > >> > i think we only need a top level GNUmakefile. all the other subdirs can >> > stay Makefile. >> >> Well, ok. I was just leaving it as-is, because that's the way it is today >> :). >> >> Like in rock-paper-scissors: >> >> GNUmakefile beats Makefile, which beats makefile. > > mmm that GNUmakefile is there for a different reason (to ignore the automake- > generated Makefile), so we dont want to go renaming it. so you dont need to > go doing something different. k. Thanks, -Garrett ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
