makefileは別のターゲットを実行します

私はこのような構造のメイクファイルを持っています：

all : 
    compile executable

clean :
    rm -f *.o $(EXEC)

「make all」を実行する前に、ターミナルで一貫して「make clean」に続けて「clear」を実行していることに気付きました。厄介なC ++コンパイルエラーを試す前に、クリーンな端末を用意するのが好きです。だから私は3番目のターゲットを追加しようとしました：

fresh :
    rm -f *.o $(EXEC)
    clear
    make all

これは機能しますが、makeの2番目のインスタンスが実行されます（私は信じています）。makeの2番目のインスタンスを実行せずに同じ機能を取得する正しい方法はありますか？

実際、あなたは正しいです。それはmakeの別のインスタンスを実行します。可能な解決策は次のとおりです。

.PHONY : clearscr fresh clean all

all :
    compile executable

clean :
    rm -f *.o $(EXEC)

fresh : clean clearscr all

clearscr:
    clear

呼び出すmake freshと、最初にcleanターゲットが取得され、次にclearscreenwhichが実行されclear、最後にallwhichがジョブを実行します。

8月4日編集

makeの-jオプションを使用した並列ビルドの場合はどうなりますか？順序を修正する方法があります。makeマニュアルのセクション4.2から：

ただし、これらのルールのいずれかが実行された場合にターゲットを強制的に更新せずに、起動するルールに特定の順序を課したい場合があります。その場合、注文のみの前提条件を定義します。注文のみの前提条件を指定するには、前提条件リストにパイプ記号（|）を配置します。パイプ記号の左側にある前提条件はすべて正常です。右側の前提条件は注文のみです：ターゲット：通常の前提条件| 注文のみの前提条件

もちろん、通常の前提条件セクションは空でもかまいません。また、同じターゲットに対して複数行の前提条件を宣言することもできます。それらは適切に追加されます。同じファイルを通常の前提条件と注文のみの前提条件の両方として宣言すると、通常の前提条件が優先されます（これらは注文のみの前提条件の動作の厳密なスーパーセットであるため）。

したがって、makefileは次のようになります。

.PHONY : clearscr fresh clean all

all :
    compile executable

clean :
    rm -f *.o $(EXEC)

fresh : | clean clearscr all

clearscr:
    clear

12月5日編集

タスク内の各コマンドは次のようになりますので、複数のmakefileのインスタンスを実行するには大したことではありませんサブシェルをとにかく。ただし、call関数を使用して再利用可能なメソッドを作成できます。

log_success = (echo "\x1B[32m>> $1\x1B[39m")
log_error = (>&2 echo "\x1B[31m>> $1\x1B[39m" && exit 1)

install:
  @[ "$(AWS_PROFILE)" ] || $(call log_error, "AWS_PROFILE not set!")
  command1  # this line will be a subshell
  command2  # this line will be another subshell
  @command3  # Use `@` to hide the command line
  $(call log_error, "It works, yey!")

uninstall:
  @[ "$(AWS_PROFILE)" ] || $(call log_error, "AWS_PROFILE not set!")
  ....
  $(call log_error, "Nuked!")

make all「新しい」ターゲットから行を削除した場合：

fresh :
    rm -f *.o $(EXEC)
    clear

次のmake fresh allように実行されるコマンドを実行するだけです。make fresh; make allです。

これをmakeの2番目のインスタンスと考える人もいますが、これは確かにmakeのサブインスタンス（make内のmake）ではなく、これが結果として発生したようです。