Re: make-3.80: `eval' bug

[Paul D. Smith]

%% address@hidden (Toomas Rosin) writes:

  tr> Given this input:

  tr>    e0 = $(foreach s,foobar,$(eval $s:))

  tr>    e0 ==

  tr> I certainly did not expect this!

Nevertheless, this one is correct.

  tr>    e1 == f
  tr>    e2 == fo

These are indeed incorrect; they should all be like e0 (empty).

This is a bug that Greg McGary already reported (although in his case,
make crashed), and I sent him a patch which I include below.  Note that
it's not clear that this will be the "real" fix as included in the next
release, but the bug will definitely be fixed somehow.  I don't really
like this fix but a better solution might be too much work for the next
release, which is meant to be a fairly quick-turnaround bug-fix
release.

  tr> I think that this is a bug, and tried to fix it.

Your fix is not correct; note that the documentation for $(eval ...)
says:

  The result of the `eval' function is always the empty string;
  thus, it can be placed virtually anywhere in a makefile without
  causing syntax errors.

Thus, there is no need (and in fact, no desire!) to keep the results of
the expansion of $(eval ...), so there's no need to track 'o" etc.

  tr> A demonstration of the power of `eval' after this fix:

  tr>    address@hidden:~ $ cat Makefile
  tr>    What = $(what)
  tr>    $(foreach s,$(what),                                     \
  tr>      $(eval prev = $(this))                                 \
  tr>      $(eval this = $s)                                      \
  tr>      $(eval What = $(wordlist 2,$(words $(What)),$(What)))  \
  tr>      $(eval $(this): $(prev)))
   
  tr>    $(what):
  tr>           @echo making $@ from $^
   
  tr>    address@hidden:~ $ make.orig what="a b c d e" e
  tr>    Makefile:2: *** target pattern contains no `%'.  Stop.
  tr>    address@hidden:~ $ make what="a b c d e" e
  tr>    making a from
  tr>    making b from a
  tr>    making c from b
  tr>    making d from c
  tr>    making e from d
  tr>    address@hidden:~ $

After applying the patch below, make will do the same thing in this
situation as your version does.


--- variable.h-dist     Wed Aug  7 20:11:19 2002
+++ variable.h  Wed Oct 23 01:35:50 2002
@@ -107,6 +107,8 @@
 extern char *expand_argument PARAMS ((char *str, char *end));
 extern char *variable_expand_string PARAMS ((char *line, char *string,
                                              long length));
+extern void pop_variable_buffer PARAMS ((char **bufp, unsigned int *lenp));
+extern void push_variable_buffer PARAMS ((char *buf, unsigned int len));
 
 /* function.c */
 extern int handle_function PARAMS ((char **op, char **stringp));
--- expand.c-dist       Thu Jul 11 02:38:57 2002
+++ expand.c    Wed Oct 23 01:37:51 2002
@@ -564,3 +564,30 @@
 
   return value;
 }
+
+/* "Pop" the current variable_buffer setting.  */
+
+void
+pop_variable_buffer (bufp, lenp)
+     char **bufp;
+     unsigned int *lenp;
+{
+  *bufp = variable_buffer;
+  *lenp = variable_buffer_length;
+
+  variable_buffer = 0;
+  initialize_variable_output ();
+}
+
+/* "Push" a previous variable_buffer setting.  */
+
+void
+push_variable_buffer (buf, len)
+     char *buf;
+     unsigned int len;
+{
+  free (variable_buffer);
+
+  variable_buffer = buf;
+  variable_buffer_length = len;
+}
--- function.c-dist     Thu Oct  3 22:13:42 2002
+++ function.c  Wed Oct 23 01:36:49 2002
@@ -1281,7 +1281,14 @@
      char **argv;
      const char *funcname;
 {
+  char *buf;
+  unsigned int len;
+
+  pop_variable_buffer(&buf, &len);
+
   eval_buffer (argv[0]);
+
+  push_variable_buffer(buf, len);
 
   return o;
 }

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist