bug-make
[Top][All Lists]
Advanced

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

Re: disparity in Paul’s Rules


From: Philip Guenther
Subject: Re: disparity in Paul’s Rules
Date: Wed, 18 Feb 2015 19:42:45 -0800

On Wed, Feb 18, 2015 at 5:01 PM, David Boyce <address@hidden> wrote:
> Am I missing something or is one of the iconic “Paul’s Rules of
> Makefiles” a little wrong (or outdated)? Rule 5 at
> http://make.mad-scientist.net/papers/rules-of-makefiles/ says:
>
> "Every non-continued line that starts with a TAB is part of a command
> script–and vice versa.”
>
> But it’s not really as simple as that. Consider this test makefile:
>
> % cat makefile
> AA = 12
>         BB #= 42
>
> .PHONY: all
> all:
>         @echo "AA=$(AA) BB=$(BB)”
>
> The BB line is prefixed with a tab and is not continued. With the
> comment character in place it provides a ‘recipe commences before
> first target. Stop.’ error but with the # removed it’s treated as a
> valid variable assignment despite the leading tab:
...
> So maybe Rule 5 needs a wording update?

I would call that a bug in make.  Putting that in a Makefile is an
exercise in unportability, especially since eight spaces there _would_
be portable.

As for updating the wording of the rule, why?  Paul's rules aren't
part of the GNU make documentation or otherwise the final word on how
GNU make behaves.  Rather, they're guidance/advice on writing good,
maintainable Makefiles.

Can you write Makefiles that violate them?  Sure, and with sufficient
justification it might even be a reasonable thing for some of his
rules, but if someone I was working with violated rule 5 intentionally
they would get a dope slap (verbal or otherwise) for being a
dumbass^W^W^Wviolating best practices.

Maybe the issue is that rule 5 is actually the closest to being a
restatement of the docs; GNU make doesn't enforce any of the others at
all (though it might not do what you want if you break them), but this
one it _almost_ does so.  Maybe the divergence between the rule and
GNU make's behavior is exactly what makes this a rule: Paul knows this
corner of GNU make's behavior and is telling you to act like it isn't
there and to follow his simpler, better rule...


Philip Guenther



reply via email to

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