Re: Bug in pattern rule parsing: how to handle?

[Philip Guenther]

On Sun, Oct 26, 2008 at 4:14 PM, Paul Smith <[EMAIL PROTECTED]> wrote:
...
> Correct, although IMO just because it has a _possible_ reasonable
> interpretation isn't enough to overcome all the reasons why we shouldn't
> allow it :-)

I agree.  I just thought of another reason to dislike it:
  %.a %.b: foo ; @echo $@

will do the echo just once for a given pair of .a and .b files.  How
many times should it do it if there's a normal file in the target
list?

So I'm with you: either ban it, or warn that it's going away and ban
it 'next time'.


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Bug in pattern rule parsing: how to handle?

[Paul Smith]

On Sun, 2008-10-26 at 15:32 -0700, Philip Guenther wrote:
> Just to be clear, the problem with mixing a pattern with a normal
> target is what happens when there's a pattern prerequisite, right?  I
> mean, the example you gave at least has a sensical _possible_
> interpretation, but this:
>foo %.c: %.c.real ; @: cp $< $@
> 
> doesn't, so make _has_ to detect and throw an error there.

Correct, although IMO just because it has a _possible_ reasonable
interpretation isn't enough to overcome all the reasons why we shouldn't
allow it :-)

-- 
---
 Paul D. Smith <[EMAIL PROTECTED]>  Find some GNU make tips at:
 http://www.gnu.org  http://make.mad-scientist.us
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Bug in pattern rule parsing: how to handle?

[Paul Smith]

On Sun, 2008-10-26 at 23:15 +0100, Sam Ravnborg wrote:
> Can you give me a more precise pointer where we have this issue
> so I can get it fixed.  I guess it is Makefile.build...

If you mean in the Linux kernel there are two places:

Makefile:1601: *** mixed implicit and normal rules.  Stop.

# Modules
/ %/: prepare scripts FORCE

and:

Makefile:442: *** mixed implicit and normal rules.  Stop.

config %config: scripts_basic outputmakefile FORCE
$(Q)mkdir -p include/linux include/config
$(Q)$(MAKE) $(build)=scripts/kconfig $@

-- 
---
 Paul D. Smith <[EMAIL PROTECTED]>  Find some GNU make tips at:
 http://www.gnu.org  http://make.mad-scientist.us
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Bug in pattern rule parsing: how to handle?

[Philip Guenther]

On Sun, Oct 26, 2008 at 2:48 PM, Paul Smith <[EMAIL PROTECTED]> wrote:
...
> Here's the issue: if you write a rule like this:
>
>foo %.c: ; @: oops
>
> it actually works!  This, I believe, should be illegal.

Just to be clear, the problem with mixing a pattern with a normal
target is what happens when there's a pattern prerequisite, right?  I
mean, the example you gave at least has a sensical _possible_
interpretation, but this:
   foo %.c: %.c.real ; @: cp $< $@

doesn't, so make _has_ to detect and throw an error there.


Philip Guenther


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Bug in pattern rule parsing: how to handle?

[Sam Ravnborg]

On Sun, Oct 26, 2008 at 05:48:11PM -0400, Paul Smith wrote:
> Hi all;
> 
> While working on some changes to 2nd expansion etc. to try to reduce
> total heap usage in GNU make, I've discovered that there is a bug in the
> current makefile parsing.  My new version doesn't have this bug (or,
> more precisely, it contains the opposite bug) and I've noticed at least
> two different build environments that stop working due to this: one is
> glibc and one is the Linux kernel (!)

Can you give me a more precise pointer where we have this issue
so I can get it fixed.
I guess it is Makefile.build...

Thanks,
Sam


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #24655] shell_var.length isn't set causing duplicates from target_environment.

[Knut St. Osmundsen]

URL:
  

 Summary: shell_var.length isn't set causing duplicates from
target_environment.
 Project: make
Submitted by: bird_tori
Submitted on: Sun 26 Oct 2008 11:02:30 PM CET
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 3.81
Operating System: Any
   Fixed Release: None

___

Details:

target_environment() uses a temporary hash table for collecting exported
variables from the sets.   This table uses variable_hash_1 and variable_hash_2
which expect the struct variable::length field to be correct and will generate
incorrect values for the shell_var since its length field is 0.

The result is, for instance, that the last test in
tests/scripts/variables/SHELL exports the wrong SHELL variable.

The fix is very simple, just initialize shell_var.length to 5 in main.c (line
1189 in r1.227). 




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Bug in pattern rule parsing: how to handle?

[Paul Smith]

Hi all;

While working on some changes to 2nd expansion etc. to try to reduce
total heap usage in GNU make, I've discovered that there is a bug in the
current makefile parsing.  My new version doesn't have this bug (or,
more precisely, it contains the opposite bug) and I've noticed at least
two different build environments that stop working due to this: one is
glibc and one is the Linux kernel (!)

So, the question is, what should we do about this?

Here's the issue: if you write a rule like this:

foo %.c: ; @: oops

it actually works!  This, I believe, should be illegal.  Indeed, if you
write the rule like this instead:

%.c foo: ; @: oops

then it fails with an error "mixed implicit and normal rules".  It's
actually an accident of parsing that we don't catch the first case: we
walk through the list and we don't recognize that we're in a pattern
rule until we hit the first target that contains a "%".  So, the first
example (that works) is treated by GNU make as:

foo: ; @: oops
%.c: ; @: oops

I really don't think this is correct... certainly treating things
differently based on the order they appear is not correct!  (I found
this problem because in my environment I happen to be walking this list
backwards at the time, so I fail on the first example but the second one
now succeeds).

I can see these choices going forward:

 1. Ignore the problem and reproduce the old behavior in the next
version of make, but don't document it so we can change it in
the future (cheap!)
 2. Reproduce the old behavior, and document it so that it becomes
the official behavior of GNU make.
 3. Reproduce the old behavior but generate a warning so that in
future versions of make we can change it so that any normal
target in an implicit rule generates an error.
 4. Fix make now so that it generates an error for this situation.

I prefer #4, or if not then #3.  If anyone has any opinions or comments
let me know.

-- 
---
 Paul D. Smith <[EMAIL PROTECTED]>  Find some GNU make tips at:
 http://www.gnu.org  http://make.mad-scientist.us
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make