bugmake - Bugs: bug #63621, Enhancement request - new built in...


bug #63621: Enhancement request - new built in variables

Submitter:  None
Submitted:  Wed 04 Jan 2023 03:56:14 PM UTC
Severity:  3 - Normal Item Group:  Enhancement
Status:  None Privacy:  Public
Assigned to:  None Open/Closed:  Open
Component Version:  None Operating System:  None
Fixed Release:  None Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup

Sun 05 Feb 2023 03:33:26 PM UTC, comment #1: 

> BTW $(info...) can't be used in the first example as the return is not always 7 bit ASCII.  $(info) seems to fail with UTF.

"UTF" is not a sufficient specification to understand this problem.  GNU make expects makefiles to be encoded in UTF-8 and all UTF-8 encoded makefiles should be properly managed.  If not, that's a bug.

Paul D. Smith <psmith>
Group administrator
Wed 04 Jan 2023 03:56:14 PM UTC, original submission:  

See discussion in https://stackoverflow.com/questions/74707248/using-call-in-a-makefile-recipe

There are multiple use cases where it would be nice for a shell operation or the expansion of a string to be able to detect if it's within a makefile recipe or makefile body.

Specific use case:
I wanted to execute a shell command that returned a string that is later used (either echoed immediately or passed on to another program)

I used a $(call...) to pass parameters from the parent Makefile, but found it did not work in recipes as it is executed at read-in time rather than shell invocation time.

e.g. within the body it would be $(shell echo $(call fn,$(var))), which worked fine. But in the recipe it would be echo "some text" where "some text" is the premature expansion of echo $(call fn,$(var)).  BTW $(info...) can't be used in the first example as the return is not always 7 bit ASCII.  $(info) seems to fail with UTF.

Suggested use cases:
- Allow a different shell in $(shell...) and recipe without explicitly invoking it each time.

- Allow a $(call...) to act differently in a recipe and when invoked in a $(shell), $(info) etc.

- Allow the build environemtn host and the build job host to be different operating system or OS versions.

Tried so far?
I've done some tests and I can't find a set of enviroment conditions that can easily be used to detect if expanded within a recipe or not.  (See https://gist.github.com/the-moog/62679586e9fba7448c8b07824565bb66)

I can work round this by pre-calculating the resulting text before the recipe is called, then only returning the one that is meaningful, but that is all a bit hacky.

I think there is a simple enhancement that would cover all of the above....

(Note: Examples for illustration only)

My Suggestions:
1: Add a .RECIPE_SHELL variable that defaults to .SHELL unless override is used.
simple example:

.SHELL = /bin/bash
override .RECIPE_SHELL := /bin/tcsh

# Execute a bash statement
res = $(shell $$((2+2)))

# Execute a tcsh statement
<TAB>setenv res $(RES); echo "res=$${res}"

2: Add a .IN_RECIPE variable that evaluates to '1' if expanded within a recipe and '' otherwise.
simple example:

myprog := echo
target := all
deps :=

# The hello macro
define hello =
$(if $(.IN_RECIPE),$(myprog) "$1",$(shell $(myprog) "$1" >> /dev/stderr))

# Say hello
$(call hello, world from make)

# Do something with a previously unknown result
$(target): $(deps) | $(call hello, Installing recipe for $(target))
<TAB>$(call hello, world from recipe)
<TAB>if something; then \
<TAB>  $(call hello, it did something);\
<TAB>else \
<TAB>  $(call hello, something went wrong);\



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by psmith (Posted a comment)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-b921.
    Corresponding source code