ChatGPT解决这个技术问题 Extra ChatGPT

How do I write the 'cd' command in a makefile?

For example, I have something like this in my makefile:

all:
     cd some_directory

But when I typed make I saw only 'cd some_directory', like in the echo command.

It's unclear what you want to do, but, in my experience with make, I never wanted to change the directory like this. Maybe you should try another approach to your solution?
It's a common newbie mistake to believe your directory is important. For most things it isn't; cd dir; cmd file can nearly always be more usefully expressed as cmd dir/file.
It's a common newbie mistake to believe your present working directory is inconsequential. Many programs, especially shell scripts, are written with a specific value of . in mind. It's true that most tools are designed in such a way that you don't need to change your pwd for it. But this isn't always true, and I don't think it's a good idea to call it a "mistake" to believe your directory may be important.
Tip: if your cd command says "No such file or directory", even when the (relative) directory does exist, check that your CDPATH environment variable is either empty or includes ".". Make executes commands with "sh", which will only find a relative path via CDPATH if it is set. This contrasts with bash, which will try . before consulting CDPATH.
To add to what @tripleee said (twelve years ago, yeesh), there are instances where the current directory is important. On MacOS, for instance, the zip command will include the entire given search path in the structure of the compressed archive, which may be undesirable.

f
falstro

It is actually executing the command, changing the directory to some_directory, however, this is performed in a sub-process shell, and affects neither make nor the shell you're working from.

If you're looking to perform more tasks within some_directory, you need to add a semi-colon and append the other commands as well. Note that you cannot use new lines as they are interpreted by make as the end of the rule, so any new lines you use for clarity need to be escaped by a backslash.

For example:

all:
        cd some_dir; echo "I'm in some_dir"; \
          gcc -Wall -o myTest myTest.c

Note also that the semicolon is necessary between every command even though you add a backslash and a newline. This is due to the fact that the entire string is parsed as a single line by the shell. As noted in the comments, you should use '&&' to join commands, which means they only get executed if the preceding command was successful.

all:
        cd some_dir && echo "I'm in some_dir" && \
          gcc -Wall -o myTest myTest.c

This is especially crucial when doing destructive work, such as clean-up, as you'll otherwise destroy the wrong stuff, should the cd fail for whatever reason.

A common usage, though, is to call make in the subdirectory, which you might want to look into. There's a command-line option for this, so you don't have to call cd yourself, so your rule would look like this

all:
        $(MAKE) -C some_dir all

which will change into some_dir and execute the Makefile in that directory, with the target "all". As a best practice, use $(MAKE) instead of calling make directly, as it'll take care to call the right make instance (if you, for example, use a special make version for your build environment), as well as provide slightly different behavior when running using certain switches, such as -t.

For the record, make always echos the command it executes (unless explicitly suppressed), even if it has no output, which is what you're seeing.


Well, not always. To suppress the echo, just put @ at the beginning of the line.
@Beta: well yes, and a dash prefix ignores the error status as well. Maybe I got a little carried away, I wanted to point out the fact that make does echos the command, regardless of what kind of command it is. And in this case, it's a command with no output, which makes the echoing seem even stranger to someone not familiar with make.
Two nits: 1. The commands should really be joined by &&, because with ; if the directory doesn’t exist and the cd fails, the shell will keep running the rest of the commands in the current directory, which can cause things like mysterious “file not found” messages for compiles, infinite loops when invoking make, or disaster for rules like clean:: cd dir; rm -rf *. 2. When invoking sub-makes, call $(MAKE) instead of make so that options will be passed on correctly.
@perreal, I usually define a pattern rule like so: %-recursive: with the body: @T="$@";$(MAKE) -C some_dir $${T%-*} (I usually have a for-loop too, to loop over a list of subdirs, the $${T%-*} is a bash expansion which removes the -recursive part of the target name) and then define explicit short-hand (and .PHONY) targets for each, like all: all-recursive, check: check-recursive, clean: clean-recursive.
@ChristianStewart, true, as was mentioned in comment 2 and 3.
C
Chnossos

Starting from GNU make 3.82 (July 2010), you can use the .ONESHELL special target to run all recipes in a single instantiation of the shell (bold emphasis mine):

New special target: .ONESHELL instructs make to invoke a single instance of the shell and provide it with the entire recipe, regardless of how many lines it contains.

.ONESHELL: # Applies to every targets in the file!

all:
    cd ~/some_dir
    pwd # Prints ~/some_dir if cd succeeded

another_rule:
    cd ~/some_dir
    pwd # Prints ~/some_dir if cd succeeded

Note that this will be equivalent to manually running

$(SHELL) $(.SHELLFLAGS) "cd ~/some_dir; pwd"
# Which gets replaced to this, most of the time:
/bin/sh -c "cd ~/some_dir; pwd"

Commands are not linked with && so if you want to stop at the first one that fails, you should also add the -e flag to your .SHELLFLAGS:

.SHELLFLAGS += -e

Also the -o pipefail flag might be of interest:

If set, the return value of a pipeline is the value of the last (rightmost) command to exit with a non-zero status, or zero if all commands in the pipeline exit successfully. This option is disabled by default.


Just note that pwd itself works, as well as `pwd` (with backticks), but $(shell pwd) and $(PWD) will still return the directory before doing the cd command, so you cannot use them directly.
Yes because variable and function expansion are done before executing the commands by make, whereas pwd and `pwd` is executed by the shell itself.
Not everybody works on legacy makefiles, and even then this answer is about knowing this possibility exists.
This can be an annoying/dangerous option because only the last command for a target can cause a failure (any earlier command failures will be ignored), and probably nobody working with you will be expecting that.
Set SHELLFLAGS to -e -c and the shell will exit at the first command that fails.
J
JoeS

Here's a cute trick to deal with directories and make. Instead of using multiline strings, or "cd ;" on each command, define a simple chdir function as so:

CHDIR_SHELL := $(SHELL)
define chdir
   $(eval _D=$(firstword $(1) $(@D)))
   $(info $(MAKE): cd $(_D)) $(eval SHELL = cd $(_D); $(CHDIR_SHELL))
endef

Then all you have to do is call it in your rule as so:

all:
          $(call chdir,some_dir)
          echo "I'm now always in some_dir"
          gcc -Wall -o myTest myTest.c

You can even do the following:

some_dir/myTest:
          $(call chdir)
          echo "I'm now always in some_dir"
          gcc -Wall -o myTest myTest.c

"Cute"? More like enough rope to shoot yourself in the foot.
Is this current directory then set for the commands just in that rule, or for all subsequently executed rules? Also, will some variation of this work under Windows?
This of course breaks for parallel execution (-jn), which is the whole point of make really.
This is a bad hack. If you ever have to resort to such thing, you are not using Makefiles for what they are for.
I won't disagree that its a bad hack that's for sure. But does demonstrate some of the wicked things you can do.
N
Nadir SOUALEM

What do you want it to do once it gets there? Each command is executed in a subshell, so the subshell changes directory, but the end result is that the next command is still in the current directory.

With GNU make, you can do something like:

BIN=/bin
foo:
    $(shell cd $(BIN); ls)

Why the $(shell ...) when cd $(BIN); ls or cd $(BIN) && ls (as @andrewdotn pointed out) would be enough.
J
Jasha

Here is the pattern I've used:

.PHONY: test_py_utils
PY_UTILS_DIR = py_utils
test_py_utils:
    cd $(PY_UTILS_DIR) && black .
    cd $(PY_UTILS_DIR) && isort .
    cd $(PY_UTILS_DIR) && mypy .
    cd $(PY_UTILS_DIR) && pytest -sl .
    cd $(PY_UTILS_DIR) && flake8 .

My motivations for this pattern are:

The above solution is simple and readable (albeit verbose)

I read the classic paper "Recursive Make Considered Harmful", which discouraged me from using $(MAKE) -C some_dir all

I didn't want to use just one line of code (punctuated by semicolons or &&) because it is less readable, and I fear that I will make a typo when editing the make recipe.

I didn't want to use the .ONESHELL special target because: that is a global option that affects all recipes in the makefile using .ONESHELL causes all lines of the recipe to be executed even if one of the earlier lines has failed with a nonzero exit status. Workarounds like calling set -e are possible, but such workarounds would have to be implemented for every recipe in the makefile.

that is a global option that affects all recipes in the makefile

using .ONESHELL causes all lines of the recipe to be executed even if one of the earlier lines has failed with a nonzero exit status. Workarounds like calling set -e are possible, but such workarounds would have to be implemented for every recipe in the makefile.


j
jackotonye

To change dir

foo: 
    $(MAKE) -C mydir

multi:
    $(MAKE) -C / -C my-custom-dir   ## Equivalent to /my-custom-dir

R
Rubik's Cube

Like this:

target:
    $(shell cd ....); \
    # ... commands execution in this directory
    # ... no need to go back (using "cd -" or so)
    # ... next target will be automatically in prev dir

Good luck!


No, this is wrong. Specifically, the $(shell cd ....) is executed when the Makefile is initially parsed, not when this particular recipe is run.
@triplee Not quite — the $(shell) is expanded only when make decides to build target. If make never needs the recipe, it won't expand it.