make-w32
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MinGW-dvlpr] Fwd: Possible bug with make version 3.81?


From: Keith Marshall
Subject: Re: [MinGW-dvlpr] Fwd: Possible bug with make version 3.81?
Date: Sun, 29 Oct 2006 09:28:13 +0000

On Sunday 29 October 2006 1:19 am, Chris Sutcliffe wrote:
> Thanx Greg for pointing out the email chain the make-w32 list.  I
> meant to send a follow up to this list but it's been a busy few days
> at work, my apologies.
>
> > Chris--I think Keith's saying that, on a different platform,
> > make-3.81 behaves as Paul would expect; if I understand that
> > correctly, then it might be worth mentioning in your bug report.

Yes, thanks Greg, for pointing to this alternative thread -- I hadn't 
been reading it.

Having done so, I now see that my simple test case didn't expose the 
limitation Chris had encountered; when I augment it, then I do observe 
the same (undesirable) effect, on the Ubuntu box.

> Most definitely.  I'll hopefully have time early next week to enter a
> bug report.

FWIW, here's my analysis of what is going on:--

1) there are three pattern rules, which specify how to build `lib%.a'; 
the first of these applies when both `%.def' and `%.o' are present; the 
remaining two apply when only one of `%.def' or `%.o' is present 
respectively.

2) there are also rules for creating the `%.o' targets, independently of 
the `lib%.a' targets.

3) the `all' rule specifies a list of `lib%.a' prerequisites, followed by 
a list of `%.o' prerequisites.

4) make-3.81 appears to evaluate the `all' prerequisites in strictly left 
to right order; the `%.o' prerequisites haven't yet been made, at the 
time when the `lib%.a' prerequisites are evaluated; hence, it chooses the 
first usable pattern rule for making a `lib%.a' *without* requiring the 
`%.o'.

5) make-3.80 and earlier seem to recognise the interdependency between 
the `all' prerequisites, and make the `%.o' targets first; hence they 
choose an even earlier pattern rule for the `lib%.a', viz. the one which 
depends on *both* `%.def' *and* `%.o' prerequisites.

Whether this is a bug, or not, isn't absolutely clear.  Eli thinks it is 
reasonable behaviour; Paul thinks it's a bug.  AIUI, Paul is the 
maintainer for `make', so in this instance his opinion probably carries 
more weight.  Notwithstanding, it seems a reasonable precaution, where 
possible, to specify the prerequisites in the `all' rule, in the order 
they should be evaluated.

Regards,
Keith.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]