Re: Potential for problems: GNU make confusing variables with targets and vice versa in hash table?

[Philip Guenther]

On Tue, Jul 15, 2008 at 4:15 PM, Garrett Cooper <address@hidden> wrote:
> I misread the manual a while back and appeared to have accidentally
> introduced a bug into a .mk file which I just fixed. However, my
> results in just poking around with my testcase provided 2 examples of
> very weird behavior when stimulating the mistake (Example #1) and its
> analog (Example #2):
>
> Example #1 ($(.DEFAULT_GOAL) isn't a target!):
>
>    address@hidden ~ $ make -f test.mk
>    echo DEFAULT GOAL foo
>    DEFAULT GOAL foo
>    echo bar
>    bar

...where test.mk starts with:
----
.DEFAULT_GOAL: foo

foo: sanity_check
        echo bar
----

If the question is "why isn't the default goal '.DEFAULT_GOAL'?", then
the answer can be found in the info pages, "9.2 Arguments to Specify
the Goals", where we read:
---
   By default, the goal is the first target in the makefile (not
counting targets that start with a period).  <...>
---

If that wasn't your question, you'll need to elaborate on what you
find unexpected.


> Example #2 (.PHONY isn't a variable!):
>
>    address@hidden ~ $ make -f test2.mk  all
>    echo "I'm not real... just a figment of your imagination"
>    I'm not real... just a figment of your imagination
>    echo "Is it [phony_baloney] real...?"
>    Is it [phony_baloney] real...?
>    echo "Hi, my name is all!"
>    Hi, my name is all!

...where test2.mk contain
  .PHONY  := phony_baloney

I'm not sure what the question here is.  The variable named '.PHONY'
is not magical at all to GNU make; the behavior you show is what you
should expect for any normal variable.  What's unexpected about the
above behavior?


> Now tell me... does this behavior constitute a bug or is it just
> considered "undefined behavior"?

GNU make is behaving as described by its manual.  The behavior is
neither incorrect nor undefined.


Philip Guenther