Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Makefile echo portability across Linux distributions #316

Open
benjamin051000 opened this issue Dec 11, 2024 · 4 comments
Open

Makefile echo portability across Linux distributions #316

benjamin051000 opened this issue Dec 11, 2024 · 4 comments

Comments

@benjamin051000
Copy link

benjamin051000 commented Dec 11, 2024

From canonical/kernel-docs#38, it appears that different distros use different symlinks for sh, which can affect the way echo behaves.

More information about non-portable echo behavior can be found here: https://unix.stackexchange.com/questions/700675/why-is-echo-e-behaving-weird-in-a-makefile

We should try to make this portion of the makefile more portable, although I'm not sure how.

One potential way we could solve this is by adding SHELL = bash in the Makefile, which forces it to use bash's echo (technically requires bash, but nearly all distros ship with bash these days). This would require us to add -e to each instance of echo where newlines may be printed.

What should we do?

@benjamin051000
Copy link
Author

benjamin051000 commented Dec 12, 2024

This would work:

BASH_FLAG=""
ifeq ($(shell basename $(shell realpath $(SHELL))), bash):
    ECHO_FLAGS="-e"
endif

# ...

help:
    @echo $(BASH_FLAG) "..."

This would prevent requiring one particular shell. This works on my distro (openSUSE TW). It correctly sets -e as the flag.

One annoying thing is you now need to write @echo $(BASH_FLAG) everywhere now... maybe it's possible to make a .PHONY echo target that calls system echo with the flag, a la wrapper function?

@SecondSkoll
Copy link
Collaborator

Is there a reason why we shouldn't pivot to printf? The only things we do with echo are newlines and a a couple of variable replacements (with regular characters, so unlikely to do anything funky).

@benjamin051000
Copy link
Author

benjamin051000 commented Jan 14, 2025

@SecondSkoll I'm not an expert, but online sentiment (e.g., on above stackexchange pages) seems to be that printf is more portable. This could be a solution.

@SecondSkoll
Copy link
Collaborator

I think moving to printf will probably be easier. I'm also no expert, so we'll just continue trying to support people as best we can. I'll get something merged in soon. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants