On Sun, Nov 8, 2009 at 12:02 PM, Garrett Cooper <[email protected]> wrote: > On Sat, Nov 7, 2009 at 6:09 PM, Garrett Cooper <[email protected]> wrote: >> On Fri, Nov 6, 2009 at 4:54 PM, Garrett Cooper <[email protected]> wrote: >>> On Fri, Nov 6, 2009 at 4:52 PM, Garrett Cooper <[email protected]> wrote: >>>> On Fri, Nov 6, 2009 at 4:23 PM, Mike Frysinger <[email protected]> wrote: >>>>> On Friday 06 November 2009 18:34:22 Matt Helsley wrote: >>>>>> On Fri, Nov 06, 2009 at 06:09:04PM -0500, Mike Frysinger wrote: >>>>>> > On Friday 06 November 2009 18:02:31 Matt Helsley wrote: >>>>>> > > On Fri, Nov 06, 2009 at 03:09:02PM -0400, Mike Frysinger wrote: >>>>>> > > > also, i thought we were going to rename the top level Makefile to >>>>>> > > > GNUmakefile and add a dummy Makefile that just spat out "sorry, ltp >>>>>> > > > requires GNU make". >>>>>> > > >>>>>> > > Bleh. Can't we just check the output of $(MAKE) --version rather than >>>>>> > > assume other makes use "Makefile"? >>>>>> > >>>>>> > the assumption is that only GNU make parses "GNUmakefile". i think >>>>>> > that's a pretty safe assumption. >>>>>> >>>>>> Right, but GNU Make also parses Makefile. >>>>> >>>>> not if a GNUmakefile exists in the same dir, or the user forces the issue >>>>> via >>>>> the -f flag >>>>> >>>>>> If some poor bastard runs: >>>>>> >>>>>> make -f Makefile >>>>>> >>>>>> where GNU Make is "make" they may be further confused. Seems like it's >>>>>> better to check what's actually running ($(MAKE)) or will run >>>>>> (like `which make` in configure) than rely on a filename hack like this. >>>>> >>>>> said poor bastard should be smacked :p. checking the value of $(MAKE) >>>>> wont >>>>> work as it could be an arbitrary number of things which could all be valid >>>>> values under GNU make. configure checks wont matter because it's the >>>>> user who >>>>> runs `make` or `gmake` or `make-some-noise`. requiring `make` to be GNU >>>>> make >>>>> in configure when the user can easily run `gmake` at make time is >>>>> pointless >>>>> user interference. >>>>> >>>>> using a different filename on the other hand is exactly what GNU make has >>>>> designed in from the get go specifically for this purpose -- when GNU >>>>> make is >>>>> required. if you honestly think people are doing something pointless like >>>>> `make -f Makefile`, then it's trivial to add a check to it to (1) check >>>>> $(MAKE) --version and include GNUmakefile or (2) $(error out). no point >>>>> in >>>>> forcing the shell/etc... overhead in the default build for the majority of >>>>> users. >>>> >>>> No, but you can do something like: >>>> >>>> ifdef MAKE_SANITY_CHECK >>>> export MAKE_SANITY_CHECK = 1 >>>> ifneq ($(lastword $(sort 3.80 $(MAKE_VERSION))),$(MAKE_VERSION)) >>>> $(error Upgrade your junk..) >>>> endif >>>> endif >>>> >>>> that way it only executes this once. >>> >>> Ugh... $(lastword ) didn't exist in 3.80... I'll change it around to >>> $(firstword ). >> >> Crap. So here are some of the high notes for changes between make 3.80 and >> 3.81: >> >> 1. $(and ) and $(or ) didn't exist [we use $(or ) once]. This can be >> replaced by an `ifeq ($(strip)) else endif'.
Fixed~ish. This one's a minor pain with $(or ). $(if ) doesn't function either because it appears to have been introduced in the same timeframe -_-... >> 2. $(abspath ) // $(realpath ) didn't exist [we use $(abspath ) >> extensively, but just in one spot -- fixed that, need to test]. Fixed. >> 3. .DEFAULT_GOAL was originally .DEFAULT_TARGET, but DID NOT exist in >> make 3.81 (this is going to be a bloody pain to hack around with, >> maybe -- depends on where I put all:). It'll be like herding cats to >> make sure that other developers don't create targets before the first >> include. Need to check. >> 4. Secondary expansion was busted as all hell in <3.81 (now this is >> going to be a serious pain point in some areas because I'll have to >> hunt down wherever I used % and $* and adjust things to work with make >> 3.80 -- this mostly affects the top-level Makefile). >> 5. Secondary expansion did NOT exist in static nor implicit rules >> (another pain point -- mostly with the top-level Makefile). .SECONDEXPANSION - fixed. >> 6. $(lastword ) didn't exist [can be replaced by $(firstword ) with >> inverse logic, maybe...]. >> 7. Some funkiness with how .PHONY was treated: >> >> 2004-09-21 Boris Kolpackov <[email protected]> >> >> * file.c (snap_deps): Mark .PHONY prerequisites as targets. >> >> 8. Variable expansion was partially broken [used underlying caller >> from $(subst ) instead of $(patsubst )]. >> 9. Now this one flat out spooks me: >> >> 2004-03-20 Paul D. Smith <[email protected]> >> >> [...] >> >> * rule.c (count_implicit_rule_limits): Don't delete patterns which >> refer to absolute pathnames in directories that don't exist: some >> portion of the makefile could create those directories before we >> match the pattern. Fixes bugs #775 and #108. >> >> This makes me think that out-of-build-tree could be REALLY broken with 3.80. >> >> 10. Ouch -- this is a really f'ed up bug: >> >> 2004-01-07 Paul D. Smith <[email protected]> >> >> [...] >> >> * job.c (construct_command_argv_internal): Add "!" to the list of >> shell escape chars. POSIX sh allows it to appear before a >> command, to negate the exit code. Fixes bug #6404. >> >> 11. Yipes -- this scares me because we do use implicit and pattern rules: >> >> 2003-04-19 Paul D. Smith <[email protected]> >> >> Fix bug #1405: allow a target to match multiple pattern-specific >> variables. >> >> * rule.c (create_pattern_var, lookup_pattern_var): Move these to >> variable.c, where they've always belonged. >> * rule.h: Move the prototypes and struct pattern_var as well. >> * variable.c (initialize_file_variables): Invoke >> lookup_pattern_var() in a loop, until no more matches are found. >> If a match is found, create a new variable set for the target's >> pattern variables. Then merge the contents of each matching >> pattern variable set into the target's pattern variable set. >> (lookup_pattern_var): Change this function to be usable >> in a loop. It takes a starting position: if NULL, start at the >> beginning; if non-NULL, start with the pattern variable after that >> position, and return the next matching pattern. >> (create_pattern_var): Create a unique instance of >> pattern-specific variables for every definition in the makefile. >> Don't combine the same pattern together. This allows us to >> process the variable handling properly even when the same pattern >> is used multiple times. >> (parse_variable_definition): New function: break out the parsing >> of a variable definition line from try_variable_definition. >> (try_variable_definition): Call parse_variable_definition to >> parse. >> (print_variable_data_base): Print out pattern-specific variables. >> * variable.h (struct variable): Remember when a variable is >> conditional. Also remember its flavor. >> (struct pattern_var): Instead of keeping a variable set, we just >> keep a single variable for each pattern. >> * read.c (record_target_var): Each pattern variable contains only a >> single variable, not a set, so create it properly. >> * doc/make.texi (Pattern-specific): Document the new behavior >> >> 12. Hmmm -- this could get nasty: >> >> 2003-01-22 Paul D. Smith <[email protected]> >> >> * function.c (func_call): Fix Bug #1744. If we're inside a >> recursive invocation of $(call ...), mask any of the outer >> invocation's arguments that aren't used by this one, so that this >> invocation doesn't "inherit" them accidentally. >> >> I'm concerned now that this is going to take 4 +/- 1 weekends to >> complete and will be semi-painful to validate... The funny thing is >> that our Makefiles were implementing some of this logic before (in a >> hodgepodge manner), so this maybe some items like these were failing >> in the past but not being caught, or were masked by all of the >> explicit target specifications which are a MFPiTA to maintain. > > I think what I need to do is run some tests in these problem areas > to figure out the gaps, now that I have an inkling of what might be > missing, so I can properly fill in the gaps if I can... Thanks, -Garrett ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
