[bug #51974] multiline (define/endef) containing target-specific assignments causes errors in /bin/sh

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[bug #51974] multiline (define/endef) containing target-specific assignments causes errors in /bin/sh

anonymous
URL:
  <http://savannah.gnu.org/bugs/?51974>

                 Summary: multiline (define/endef) containing target-specific
assignments causes errors in /bin/sh
                 Project: make
            Submitted by: oss542
            Submitted on: Sat 09 Sep 2017 08:45:50 PM UTC
                Severity: 3 - Normal
              Item Group: Bug
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
       Component Version: 4.2.1
        Operating System: POSIX-Based
           Fixed Release: None
           Triage Status: None

    _______________________________________________________

Details:

case 1:
Makefile :

define EXELNK1
$(1): OBJ1=xOBJ1
$(1): OBJ2=xOBJ2
endef
$(call EXELNK1, utl1)
utl1:;@echo "jfh1:pt1:$(OBJ1):$(OBJ2):"

result of invoking make :
expected: jfh1:pt1:xOBJ1:xOBJ2:
actual:

/bin/sh: -c: line 0: unexpected EOF while looking for matching `"'
/bin/sh: -c: line 1: syntax error: unexpected end of file
make: *** [Makefile:6: utl1] Error 2


case 2:
Makefile:

define EXELNK1
$(1): OBJ1=xOBJ1
endef
$(call EXELNK1, utl1)
utl1:;@echo "jfh1:pt1:$(OBJ1):$(OBJ2):"

result of invoking make : works as expected


case 3:
Makefile:

define EXELNK1
$(1): OBJ2=xOBJ2
endef
$(call EXELNK1, utl1)
utl1:;@echo "jfh1:pt1:$(OBJ1):$(OBJ2):"

result of invoking make : works as expected





    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?51974>

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


_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

[bug #51974] multiline (define/endef) containing target-specific assignments causes errors in /bin/sh

anonymous
Follow-up Comment #1, bug #51974 (project make):

This is also not a bug but rather an example where you need to use $(eval).

I suggest you email your question about how to do what you want to the
help-make mailing list:
    https://lists.gnu.org/mailman/listinfo/help-make

instead of filing bugs...which are not bugs but rather make doing exactly what
it's documented to do.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?51974>

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


_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

[bug #51974] multiline (define/endef) containing target-specific assignments causes errors in /bin/sh

anonymous
Follow-up Comment #2, bug #51974 (project make):

case 4:
Makefile:

define EXELNK1
$(1): OBJ1=xOBJ1
endef
define EXELNK2
$(1): OBJ2=xOBJ2
endef
$(call EXELNK1, utl1)
$(call EXELNK2, utl1)
utl1:;@echo "jfh1:pt1:$(OBJ1):$(OBJ2):"

result of invoking make : works as expected


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?51974>

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


_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

[bug #51974] multiline (define/endef) containing target-specific assignments causes errors in /bin/sh

anonymous
Follow-up Comment #3, bug #51974 (project make):

As the other poster points out here, $(eval) was required to parse the result
of the $(call) reference.  This resolves this issue.                          
                                 Many thanks for your patience and advice.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?51974>

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


_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

[bug #51974] multiline (define/endef) containing target-specific assignments causes errors in /bin/sh

anonymous
Follow-up Comment #4, bug #51974 (project make):

I can't dispute Anonymous's advice, which was what I first thought of too, but
I don't think it's clearly documented, neither in the GNU make manual nor in
this vein of bugs, how makefile fragments like these are being parsed.
Perhaps this example will help explain what was going on in the other cases:

mad@shuttle:~/tmp/make-51972$ cat case-6.make
define MACRO
A: B
hello
endef
$(MACRO)
mad@shuttle:~/tmp/make-51972$

(The pointlessness of $(call) with no arguments is documented.)

Look away now if you want to guess the behavior on &quot;make -f
case-6.make&quot;.







mad@shuttle:~/tmp/make-51972$ make -f case-6.make
make: *** No rule to make target 'B
hello', needed by 'A'.  Stop.
mad@shuttle:~/tmp/make-51972$

The result of the variable expansion clearly is being parsed as makefile
syntax, in that it has defined a rule (one without a recipe), but the line
breaks aren't being treated how they would be in a makefile fragment.  Is that
reasonable?  I'll buy it.  But is it obvious?

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?51974>

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


_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

[bug #51974] call on multiline (define/endef) behavior not well-documented

anonymous
Update of bug #51974 (project make):

              Item Group:                     Bug => Documentation          
                 Summary: multiline (define/endef) containing target-specific
assignments causes errors in /bin/sh => call on multiline (define/endef)
behavior not well-documented

    _______________________________________________________

Follow-up Comment #5:

For J. Hart: I do also recommend that you ask questions first on the
[hidden email] or [hidden email] mailing lists to be sure the behavior
you're seeing is really incorrect, before filing bugs here.

The make parser doesn't "go backwards": it will first read a line, then expand
the line, then interpret the line.  It doesn't go back after expanding the
line to re-interpret the newline characters, so the entire results of
expansion is treated as a single logical line by the make parser.  I did try,
when first implementing eval, to instead just have things re-interpreted after
expansion always but it ended up being a real mess.  Requiring an explicit
eval is not always intuitive at first but it actually makes things much more
coherent in general.

I do agree that the behavior could be better documented so I've modified this
to a doc bug.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?51974>

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


_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

[bug #51974] call on multiline (define/endef) behavior not well-documented

anonymous
Update of bug #51974 (project make):

                  Status:                    None => Fixed                  
             Open/Closed:                    Open => Closed                
           Fixed Release:                    None => SCM                    

    _______________________________________________________

Follow-up Comment #6:

I added a new section to the GNU make manual which discusses how lines are
parsed, and updated the define/endef section to be a bit more detailed.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?51974>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/


_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

[bug #51974] call on multiline (define/endef) behavior not well-documented

anonymous
Follow-up Comment #7, bug #51974 (project make):

Either the 'new' documentation is not entirely correct, or there is a bug in
the current expansion logic (or I am misunderstanding something).

The documentation states:

----
4. Expand elements of the line which appear in an immediate expansion context
(see How make Reads a Makefile).
5. Scan the line for a separator character, such as ‘:’ or ‘=’, to
determine whether the line is a macro assignment or a rule (see Recipe
Syntax).
6. Internalize the resulting operation and read the next line.

An important consequence of this is that a macro can expand to an entire rule,
if it is one line long.
----

The last statement assumes that a line containing only a variable reference,
such as


$(myrule)


presents an immediate expansion context, although it does not meet any of the
stated forms of an immediate expansion context.

If it were, then this should also work:


myassignment = var = val

$(myassignment)


Step 5 of the list above would apply to the last line of this example (it
expands to 'var = val'). However, make fails with a "missing separator" error.
A slightly different error, "empty variable name", results from this
variation:


myassignment = var := val

$(myassignment)


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?51974>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/