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'.
> 2. $(abspath ) // $(realpath ) didn't exist [we use $(abspath )
> extensively, but just in one spot -- fixed that, need to test].
> 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.
> 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).
> 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
