I am working on a Makefile that gets executed in a Linux environment and Windows environment (through MINGW64). The script has a variable which is pointing to the shell command which should be used:
SHELL:=/usr/bin/env bash
Later on, that variable is being used to run a shell script:
${SHELL} ./utils/tests.sh
On Linux that works just fine but on Windows with MINGW64 (Git Bash) it fails because /usr/bin/env is being replaced with C:/Program Files/Git/usr/local and there is a space character in "Program Files" which breaks the path in the Makefile.
To solve the issue on Windows, I can put ${SHELL} in quotes to make sure that the space character is kept:
"${SHELL}" ./utils/tests.sh
However, this is breaking on Linux environments because it becomes a string now and "/usr/bin/env bash" is not executable.
So I came up with this solution:
ifeq ($(OS),Windows_NT)
"${SHELL}" ./utils/tests.sh
else
${SHELL} ./utils/tests.sh
endif
That's now working in both environments (Linux & MINGW64) but it comes with the downside of having 5 lines of code everywhere where I want to run a script. Ideally, I would like to assign the variable just once. I tried this but it doesn't work either:
ifeq ($(OS),Windows_NT)
SHELL:="/usr/bin/env" bash
else
SHELL:=/usr/bin/env bash
endif
test: clean build
${SHELL} ./utils/tests.sh
Does anyone have a clever solution to my problem?
You could replace:
SHELL:=/usr/bin/env bash
with one of these (or with whatever path directly leads to Bash's executable):
SHELL:=/bin/bash
SHELL:=/usr/bin/bash
SHELL:=bash
which would eliminate the space from the equation.
That being said, you should also be able to run the commands directly, i.e.:
./utils/tests.sh
instead of:
${SHELL} ./utils/tests.sh
which would eliminate the need to set and use variable SHELL altogether.
Related
I found in a makefile the following commands:
$(var):
mkdir -p $(#D)
What is the meaning of this command?
$(VAR) expands to the value of the variable VAR. This is a Make variable (not a shell etc variable). For example, if earlier in your Makefile you define
VAR=ick/poo
then VAR expands to ick/poo, and #D in your recipe expands to the directory part, ick.
As you seem to be confused about the relationship between shell and make, I should perhaps point out that these are two different languages, though in a Makefile, you will encounter both; the recipes - the parts which are indented by a tab - will be passed to a shell for evaluation (though normally the shell will be /bin/sh, not Bash, unless you specifically override the Make variable SHELL to force it).
In the shell, by the way, the superficially similar construct $(cmd) performs a command substitution; that is, the command cmd will be evaluated and its output will be inserted as text. So for example,
echo Running in $(pwd)
will print
Running in /home/you
if executed in the directory /home/you (the command pwd prints out your current working directory). ... Though in a Makefile, the dollar sign will normally be evaluated and consumed by make itself; so to pass a literal dollar sign to the shell, you have to double it.
test:
echo Running in $$(pwd)
As already explained by #tripleee $(var) expands to the variable. Because it is here listed before a colon it means that it is a target in a Makefile.
For $(#D) see 10.5.3 Automatic Variables in the make manual:
The directory part of the file name of the target, with the trailing slash removed. If the value of ‘$#’ is dir/foo.o then ‘$(#D)’ is dir. This value is . if ‘$#’ does not contain a slash.
NOTE: This is NOT a shell script. This is a makefile. Please use "man make" for a description about what "make" does.
This is bothering me more than it should and has me completely stumped. I feel like like finding the answer will have some good learning opportunities so hopefully it's relevant.
I do embedded C development with Vim and have a setup for hobbyist stuff with Arduino (using Arduino Makefile). I use :make with some shortcuts with build projects.
An external define resolves the Arduino Makefile root directory in the project level Makefile: 'ARDMK_DIR=/usr/local/opt/arduino-mk'. This is define as an export in my shell (zsh). This is where it gets weird:
Using make at the shell prompt the project builds fine:
make -d
This program built for i386-apple-darwin11.3.0
Reading makefiles...
Reading makefile `Makefile'...
Reading makefile `/usr/local/opt/arduino-mk/Arduino.mk' (search path) (no ~ expansion)...
However using :make in Vim the define becomes something from an old install:
:make
This program built for i386-apple-darwin11.3.0
Reading makefiles...
Reading makefile `Makefile'...
Reading makefile `/usr/local/Cellar/arduino-mk/1.5.2/Arduino.mk' (search path) (no ~ expansion)...
Makefile:24: /usr/local/Cellar/arduino-mk/1.5.2/Arduino.mk: No such file or directory
I cannot for the life of me find where ARDMK_DIR is being re-defined to '/usr/local/Cellar/arduino-mk/1.5.2'. Things I have tried:
setlocal makeprg=echo\ $ARDMK_DIR\ &&\ make\ -d\: echo comes back with my shell define (/usr/local/opt/arduino-mk), but make fails with the error above!!
:echo $ARDMK_DIR: again returns my shell define.
ag my home directory for ARDMK_DIR, the only place it is defined is in my shell exports. Did since for my root directory to and same thing. Same thing for $VIMRUNTIME
Even vim-disptach works fine calling the same makeprg?!
Re-define ARDMK_DIR in the project Makefile. Everything builds find as expected. I don't want to do this however as I compile with different systems.
The same vim config works on other macOS and Linux systems with expected behaviour.
Some where between echo and the actual execution of make, ARDMK_DIR is being re-defined. Why and can anyone think of a way of finding out where and solving this?
Zsh has multiple init files that are sourced. The file .zshenv is always sourced, when the shell starts and the file .zshrc is only sourced when the shell is started in interactive mode.
If you define the variable ARDMK_DIR with different values in .zshenv and in .zshrc, the value from .zshrc will be used when you work interactive with the shell (entering commands, starting Vim, ...).
But when Vim starts a command it will start a non-interactive shell. In that case only the file .zshenv will be sourced, so you get the value from that file.
One question left:
Why did the following command first echo the correct value, but make uses the wrong?
:setlocal makeprg=echo\ $ARDMK_DIR\ &&\ make\ -d\
For testing, I started Vim under strace. Then :
:set makeprg=echo\ $EDITOR
:make
In the strace file I found the following line:
execve("/usr/bin/zsh", ["/usr/bin/zsh", "-c", "echo vi 2>&1| tee /tmp/vdxR5DH/"...], [/* 86 vars */]) = 0
As you can see, Vim executes echo vi, so it already expanded the environment variable $EDITOR to its value before calling the shell.
So the answer to the above question is, that the echo command echos the text, that Vim inserted into the command line while the make command gets the the variable value from the environment. As it is a non-interactive shell, it is the value from .zshenv.
While the man for env on Linux seems to indicate that you can set new environment variables before executing a command. Unfortunately, when I set new variables in a file's shebang on Linux systems, the file never executes.
#!/usr/bin/env VAR1=foo bash
echo $VAR1
When I execute this file on a CentOS or Ubuntu machine, it just sits there.
$ ./shell-env.sh
<nothing happens>
What I find particularly bizarre is this works perfectly fine on OS X with BSD env.
$ ./shell-env.sh
foo
$
Is this just a difference between BSD env and Linux env? Why do the man pages for Linux seem to say it should work the same way as on BSD?
P.S. My use case here is to override the PATH variable, so I can try to find a ruby on the system but that's not on the PATH.
Thank you in advance!
There's a way to manipulate the environment before executing a Ruby script, without using a wrapper script of some kind, but it's not pretty:
#!/bin/bash
export FOO=bar
exec ruby -x "$0" "$#"
#!ruby
puts ENV['FOO']
This is usually reserved for esoteric situations where you need to manipulate e.g. PATH or LD_LIBRARY_PATH before executing the program, and it needs to be self-contained for some reason. It works for Perl and possibly others too!
I want to write a Makefile which would run tests. Test are in a directory './tests' and executable files to be tested are in the directory './bin'.
When I run the tests, they don't see the exec files, as the directory ./bin is not in the $PATH.
When I do something like this:
EXPORT PATH=bin:$PATH
make test
everything works. However I need to change the $PATH in the Makefile.
Simple Makefile content:
test all:
PATH=bin:${PATH}
#echo $(PATH)
x
It prints the path correctly, however it doesn't find the file x.
When I do this manually:
$ export PATH=bin:$PATH
$ x
everything is OK then.
How could I change the $PATH in the Makefile?
Did you try export directive of Make itself (assuming that you use GNU Make)?
export PATH := bin:$(PATH)
test all:
x
Also, there is a bug in you example:
test all:
PATH=bin:${PATH}
#echo $(PATH)
x
First, the value being echoed is an expansion of PATH variable performed by Make, not the shell. If it prints the expected value then, I guess, you've set PATH variable somewhere earlier in your Makefile, or in a shell that invoked Make. To prevent such behavior you should escape dollars:
test all:
PATH=bin:$$PATH
#echo $$PATH
x
Second, in any case this won't work because Make executes each line of the recipe in a separate shell. This can be changed by writing the recipe in a single line:
test all:
export PATH=bin:$$PATH; echo $$PATH; x
By design make parser executes lines in a separate shell invocations, that's why changing variable (e.g. PATH) in one line, the change may not be applied for the next lines (see this post).
One way to workaround this problem, is to convert multiple commands into a single line (separated by ;), or use One Shell special target (.ONESHELL, as of GNU Make 3.82).
Alternatively you can provide PATH variable at the time when shell is invoked. For example:
PATH := $(PATH):$(PWD)/bin:/my/other/path
SHELL := env PATH=$(PATH) /bin/bash
Path changes appear to be persistent if you set the SHELL variable in your makefile first:
SHELL := /bin/bash
PATH := bin:$(PATH)
test all:
x
I don't know if this is desired behavior or not.
What I usually do is supply the path to the executable explicitly:
EXE=./bin/
...
test all:
$(EXE)x
I also use this technique to run non-native binaries under an emulator like QEMU if I'm cross compiling:
EXE = qemu-mips ./bin/
If make is using the sh shell, this should work:
test all:
PATH=bin:$PATH x
To set the PATH variable, within the Makefile only, use something like:
PATH := $(PATH):/my/dir
test:
#echo my new PATH = $(PATH)
I am trying to use setenv variable in my makefile but when I execute my make file it gives setenv: command not found.
How can I use it?
Actually I wanted to run a shell script which sets multiple environment variables.
Since the list is very huge I dont have an option except to use the scripts. I cant set them manually like
abcd:= /xx/yy/zz
Please suggest.
P.S. the same command
setenv xxx yyy works very well in shell
it just fails when I use in makefile directly or makefile with a script having this command.
'
Why do not you use export command ?
Running the script to set the environment variable will not work as the shell run a separate process & will not reflect in your current shell. You will need to source the shell script. You can use source or . based on your shell. Following is a sample for your reference where setvar.sh sets a variable & print.sh prints it; in the Makefile (mkfile) setvar.sh is being sourced using .
$ cat setvar.sh
export TEST=ABC
$ cat print.sh
echo $TEST
$ cat mkfile
test:
. ./setvar.sh && ./print.sh
.SILENT:test
$ make -f mkfile
ABC
You can also include I guess for example,
$ cat mkfile2
include setvar.sh
test:
./print.sh
.SILENT:test
$ make -f mkfile2
ABC
Hope this helps!
Look at
make -e
and Communicating Variables to a Sub-make
I think setenv is not a builtin to the sh shell. If you are using GNU Make that is the default shell used. In your situation you probably want to use a different shell, like bash. You do this by setting the SHELL variable in the makefile to what you want like:
SHELL := /usr/bin/bash
For more information checkout this section of the GNU Make manual. It details the different behavior of the SHELL variable and how it is, or isn't inherited from the shell make is invoked from on different platforms.
EDIT: I agree with the implication of the other posters that you are probably not setting enviroment variables the way you think you should be and would not be using the setenv command at. I am just responding to your original question. To learn about variables in make files checkout these other sections in the GNU Make manual.
export MY_VAR := "/package/your_path"