Re: Help-make Digest, Vol 76, Issue 8

2009/3/17 <address@hidden>

Send Help-make mailing list submissions to
address@hidden

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.gnu.org/mailman/listinfo/help-make
or, via email, send a message with subject or body 'help' to
address@hidden

You can reach the person managing the list at
address@hidden

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Help-make digest..."

Today's Topics:

1. Re: define issues (Philip Guenther)
2. Re: Help-make Digest, Vol 76, Issue 7 (xiangfeng shen)
3. Re: define issues (Eli Zaretskii)
4. Re: define issues (Philip Guenther)
5. RE: define issues (Appleton, R. (Rick))

----------------------------------------------------------------------

Message: 1
Date: Mon, 16 Mar 2009 16:47:16 -0700
From: Philip Guenther <address@hidden>
Subject: Re: define issues
To: "Appleton, R. (Rick)" <address@hidden>
Cc: address@hidden
Message-ID:
<address@hidden>
Content-Type: text/plain; charset=ISO-8859-1

2009/3/16 Appleton, R. (Rick) <address@hidden>:
> I'm having issues using defines in a Makefile.
> The following makefile:
>
> =====================
> PROGRAMS = server client
>
> .PHONY: all
> all: $(PROGRAMS)
>
> server_LIBS := priv protocol
> client_LIBS := protocol
>
> define PROGRAM_template
>
> $(1):
> cc $($(1)_LIBS) -o $$@
>
> endef
>
> $(foreach prog,$(PROGRAMS),$(eval $(call PROGRAM_template,$(prog))))
> =====================
>
> generates this output
> cc priv protocol -o server
> cc protocol -o client

Could you elaborate on why you choose to use $(eval) for that? I ask because
1) $(eval) has proven to be difficult for people to understand and
reason about, and
2) the problem given can be solved without using $(eval):

-----
PROGRAMS = server client

.PHONY: all
all: $(PROGRAMS)

server_LIBS := priv protocol
client_LIBS := protocol

$(PROGRAMS):
cc $(address@hidden) -o $@
-----

Practically all the uses of $(eval) that I've seen posted here have
been buggy, unnecessary, or both.

> yet the following file
...
> generates this (unexpected) output
> cc -o server
> cc protocol -o client
>
> Does anyone have an idea why it might be doing this?

Makes perfect sense to me. You just have to think about when the
various variable references are being expanded (_before_ $(eval) is
getting the text to evaluate, _during_ that evaluation, or
_afterwards_ when the rule is being processed) versus when the various
variable settings are actually being performed.

<soapbox>

Let me apologize in advance if my next statement appears to be a
personal insult. It's not meant as such, as I hope I'll make clear.

To be blunt, $(eval) should be relegated to the "EXPERTS ONLY" section
of the manual...and if you don't understand what I meant by "before vs
during vs afterwards", then you're not an expert and should not use
it.

This isn't meant to be a slam on you or the others that have tried to
use $(eval) and been tripped up by how it works. I think $(eval) was
not documented with enough warnings about how non-intuitive it is, so
that it looks like a simple way for people to write more 'procedural'
makefile. In my experience, most users are slightly uncomfortable
with make's declarative operation, so the option to write a makefile
as if it was a procedural language is seductive. The problem is that
$(eval) was designed for the complex cases, where double expansion is
critical, and not for the simple cases, where double expansion is a
trap to drive users insane.

Perhaps you get all the above and my mention of
"before/during/afterwards" was all it took for you to see how to solve
your problem. That good, but I strongly suggest you reconsider your
use of $(eval) and whether it's actually necessary or just an attempt
to jam make into a different paradigm of _expression_.

Similarly, I suggest to the GNU make maintainers to think *real hard*
about what they can do to ease the support burden that has been
created by $(eval) being freely used by people that think it simpler
than it is, perhaps starting with a pile of warnings and cookbook
examples in the info pages...but I'll leave that to someone who
actually likes $(eval).

</soapbox>

Philip Guenther

------------------------------

Message: 2
Date: Mon, 16 Mar 2009 19:32:24 -0800
From: xiangfeng shen <address@hidden>
Subject: Re: Help-make Digest, Vol 76, Issue 7
To: address@hidden
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"

Hi,

The macro PROGRAM_template do not expand by first parse when reading the
makefile.
So the server_LIBS is not defined at all when calling macro
PROGRAM_template.
The $($(1)_LIBS) expand to nothing when called.

regards.
carl shen

2009/3/16 <address@hidden>

> Send Help-make mailing list submissions to
> address@hidden
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.gnu.org/mailman/listinfo/help-make
> or, via email, send a message with subject or body 'help' to
> address@hidden
>
> You can reach the person managing the list at
> address@hidden
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Help-make digest..."
>
>
> Today's Topics:
>
> 1. define issues (Appleton, R. (Rick))
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 16 Mar 2009 09:05:10 +0100
> From: "Appleton, R. (Rick)" <address@hidden>
> Subject: define issues
> To: <address@hidden>
> Message-ID:
> <address@hidden>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I'm having issues using defines in a Makefile.
> The following makefile:
>
> =====================
> PROGRAMS = server client
>
> .PHONY: all
> all: $(PROGRAMS)
>
> server_LIBS := priv protocol
> client_LIBS := protocol
>
> define PROGRAM_template
>
> $(1):
> cc $($(1)_LIBS) -o $$@
>
> endef
>
> $(foreach prog,$(PROGRAMS),$(eval $(call PROGRAM_template,$(prog))))
> =====================
>
> generates this output
> cc priv protocol -o server
> cc protocol -o client
>
> yet the following file
> =====================
> PROGRAMS = server client
>
> .PHONY: all
> all: $(PROGRAMS)
>
> client_LIBS := protocol
>
> define PROGRAM_template
>
> # The following line has moved inside the define
> server_LIBS := priv protocol
>
> $(1):
> cc $($(1)_LIBS) -o $$@
>
> endef
>
> $(foreach prog,$(PROGRAMS),$(eval $(call PROGRAM_template,$(prog))))
> =====================
>
> generates this (unexpected) output
> cc -o server
> cc protocol -o client
>
> Does anyone have an idea why it might be doing this?
>
> My GNU Make version is 3.80
> This e-mail and its contents are subject to the DISCLAIMER at
> http://www.tno.nl/disclaimer/email.html
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.gnu.org/pipermail/help-make/attachments/20090316/256949fe/attachment.html
>
> ------------------------------
>
> _______________________________________________
> Help-make mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/help-make
>
>
> End of Help-make Digest, Vol 76, Issue 7
> ****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.gnu.org/pipermail/help-make/attachments/20090316/9bbaa4a4/attachment.html

------------------------------

Message: 3
Date: Tue, 17 Mar 2009 06:16:53 +0200
From: Eli Zaretskii <address@hidden>
Subject: Re: define issues
To: Philip Guenther <address@hidden>
Cc: address@hidden
Message-ID: <address@hidden>

> Date: Mon, 16 Mar 2009 16:47:16 -0700
> From: Philip Guenther <address@hidden>
> Cc: address@hidden
>
> To be blunt, $(eval) should be relegated to the "EXPERTS ONLY" section
> of the manual...and if you don't understand what I meant by "before vs
> during vs afterwards", then you're not an expert and should not use
> it.
> [...]
> Similarly, I suggest to the GNU make maintainers to think *real hard*
> about what they can do to ease the support burden that has been
> created by $(eval) being freely used by people that think it simpler
> than it is, perhaps starting with a pile of warnings and cookbook
> examples in the info pages...but I'll leave that to someone who
> actually likes $(eval).

Maybe we should just improve the documentation to better explain what
$(eval) does and how, so that even non-experts will see the light.
What is missing from the current docs that you think should be there
(and I don't mean the warning to stay away)?

------------------------------

Message: 4
Date: Mon, 16 Mar 2009 23:55:08 -0700
From: Philip Guenther <address@hidden>
Subject: Re: define issues
To: Eli Zaretskii <address@hidden>
Cc: address@hidden
Message-ID:
<address@hidden>
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Mar 16, 2009 at 9:16 PM, Eli Zaretskii <address@hidden> wrote:
...
> Maybe we should just improve the documentation to better explain what
> $(eval) does and how, so that even non-experts will see the light.
> What is missing from the current docs that you think should be there
> (and I don't mean the warning to stay away)?

Double-evaluation in various languages has been a source of bugs and
security holes for years, but you don't think people should be warned
away from this?

"Here folks, see how cleanly this slices your fingers off? Ain't it
great!?! Oh, and the results are completely unlike normal makefiles
and unmaintainable by the people who follow you! Perfect job
security, assuming you keep your job after you've lost your fingers!"

For myself, I'm not experienced enough in its use to make a
recommendation about how it should be used; I *don't* think it should
be removed, but I'm not going to use it until it's the last resort.
I've dealt with double-eval crap in enough other languages to be able
to see where the problems lie in someone else's usage, but mostly to
not want to go there.

Philip Guenther

------------------------------

Message: 5
Date: Tue, 17 Mar 2009 09:01:01 +0100
From: "Appleton, R. (Rick)" <address@hidden>
Subject: RE: define issues
Cc: <address@hidden>
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"

Thank you Philip for your response. I've been using this construct in a top-level Makefile for a non-recursive make system (inspired by http://blogs.designingpatterns.com/urban-jungle/category/build-systems/make-build-systems/). The example I posted was just me trying to get a better understanding of how the system could/would be used. After sending the mail I spent more time with the actual system (rather than the sample I posted), and got a better understanding of eval. This morning I was able to spot the error in the sample as well, so the time spent on the system has definately helped.

I do agree with you that the eval function is quite difficult to parse for someone new to it, and the manual (I've been using http://www.gnu.org/software/make/manual/make.html#Top) could definately be clearer about it.

Thanks again for your help,
Rick

-----Original Message-----
From: Philip Guenther [mailto:address@hidden]
Sent: Tue 3/17/2009 12:47 AM
To: Appleton, R. (Rick)
Cc: address@hidden
Subject: Re: define issues

2009/3/16 Appleton, R. (Rick) <address@hidden>:
> I'm having issues using defines in a Makefile.
> The following makefile:
>
> =====================
> PROGRAMS = server client
>
> .PHONY: all
> all: $(PROGRAMS)
>
> server_LIBS := priv protocol
> client_LIBS := protocol
>
> define PROGRAM_template
>
> $(1):
> cc $($(1)_LIBS) -o $$@
>
> endef
>
> $(foreach prog,$(PROGRAMS),$(eval $(call PROGRAM_template,$(prog))))
> =====================
>
> generates this output
> cc priv protocol -o server
> cc protocol -o client

Could you elaborate on why you choose to use $(eval) for that? I ask because
1) $(eval) has proven to be difficult for people to understand and
reason about, and
2) the problem given can be solved without using $(eval):

-----
PROGRAMS = server client

.PHONY: all
all: $(PROGRAMS)

server_LIBS := priv protocol
client_LIBS := protocol

$(PROGRAMS):
cc $(address@hidden) -o $@
-----

Practically all the uses of $(eval) that I've seen posted here have
been buggy, unnecessary, or both.

> yet the following file
...
> generates this (unexpected) output
> cc -o server
> cc protocol -o client
>
> Does anyone have an idea why it might be doing this?

Makes perfect sense to me. You just have to think about when the
various variable references are being expanded (_before_ $(eval) is
getting the text to evaluate, _during_ that evaluation, or
_afterwards_ when the rule is being processed) versus when the various
variable settings are actually being performed.

<soapbox>

Let me apologize in advance if my next statement appears to be a
personal insult. It's not meant as such, as I hope I'll make clear.

To be blunt, $(eval) should be relegated to the "EXPERTS ONLY" section
of the manual...and if you don't understand what I meant by "before vs
during vs afterwards", then you're not an expert and should not use
it.

This isn't meant to be a slam on you or the others that have tried to
use $(eval) and been tripped up by how it works. I think $(eval) was
not documented with enough warnings about how non-intuitive it is, so
that it looks like a simple way for people to write more 'procedural'
makefile. In my experience, most users are slightly uncomfortable
with make's declarative operation, so the option to write a makefile
as if it was a procedural language is seductive. The problem is that
$(eval) was designed for the complex cases, where double expansion is
critical, and not for the simple cases, where double expansion is a
trap to drive users insane.

Perhaps you get all the above and my mention of
"before/during/afterwards" was all it took for you to see how to solve
your problem. That good, but I strongly suggest you reconsider your
use of $(eval) and whether it's actually necessary or just an attempt
to jam make into a different paradigm of _expression_.

Similarly, I suggest to the GNU make maintainers to think *real hard*
about what they can do to ease the support burden that has been
created by $(eval) being freely used by people that think it simpler
than it is, perhaps starting with a pile of warnings and cookbook
examples in the info pages...but I'll leave that to someone who
actually likes $(eval).

</soapbox>

Philip Guenther

This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.gnu.org/pipermail/help-make/attachments/20090317/e4c7f249/attachment.html

------------------------------

_______________________________________________
Help-make mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/help-make

End of Help-make Digest, Vol 76, Issue 8
****************************************

From:	xiangfeng shen
Subject:	Re: Help-make Digest, Vol 76, Issue 8
Date:	Sat, 21 Mar 2009 08:20:04 +0800