Return to Answer

deleted 1 character in body

Source Link

edited Dec 23, 2024 at 11:45

Generally, I would use as much of the make built-ins as possible. Specifically:

I would normally not specify the C++ (or C) compiler. The default for gnu make is g++; the system should be set up to use the most adequate one — for example, through a symbolic link from g++ to the g++ du jour. Changing that compiler, which may happen at any point, should not make it necessary to touch the Makefile. An explicit compiler specification would (only) make sense for projects which have special needs like depending on a specific compiler version, or a cross compiler.
There is no need to tell gnu make how to compile and link C++ files to produce an executable. This case is so common that it is built-in: The line @$$(CXX) $(CXXFLAGS) $(SRC_FILE) -o $(APP_NAME) is exactly the built-in rule. Making it explicit adds nothing except trouble for a reviewer, possibly yourself later on: "Since the author was explicit, they probably wanted to do something differently. Where is the intended deviation from the built-in rules?" It also introduces an opportunity for hard-to-find mistakes: Misspelling a built-in variable silently results in an empty string.

The core of your Makefile, therefore, is a simple $(APP_NAME): $(SRC_FILE).

Generally, I would use as much of the make built-ins as possible. Specifically:

I would normally not specify the C++ (or C) compiler. The default for gnu make is g++; the system should be set up to use the most adequate one — for example, through a symbolic link from g++ to the g++ du jour. Changing that compiler, which may happen at any point, should not make it necessary to touch the Makefile. An explicit compiler specification would (only) make sense for projects which have special needs like depending on a specific compiler version, or a cross compiler.
There is no need to tell gnu make how to compile and link C++ files to produce an executable. This case is so common that it is built-in: The line @$(CXX) $(CXXFLAGS) $(SRC_FILE) -o $(APP_NAME) is exactly the built-in rule. Making it explicit adds nothing except trouble for a reviewer, possibly yourself later on: "Since the author was explicit, they probably wanted to do something differently. Where is the intended deviation from the built-in rules?" It also introduces an opportunity for hard-to-find mistakes: Misspelling a built-in variable silently results in an empty string.

The core of your Makefile, therefore, is a simple $(APP_NAME): $(SRC_FILE).

Generally, I would use as much of the make built-ins as possible. Specifically:

I would normally not specify the C++ (or C) compiler. The default for gnu make is g++; the system should be set up to use the most adequate one — for example, through a symbolic link from g++ to the g++ du jour. Changing that compiler, which may happen at any point, should not make it necessary to touch the Makefile. An explicit compiler specification would (only) make sense for projects which have special needs like depending on a specific compiler version, or a cross compiler.
There is no need to tell gnu make how to compile and link C++ files to produce an executable. This case is so common that it is built-in: The line $(CXX) $(CXXFLAGS) $(SRC_FILE) -o $(APP_NAME) is exactly the built-in rule. Making it explicit adds nothing except trouble for a reviewer, possibly yourself later on: "Since the author was explicit, they probably wanted to do something differently. Where is the intended deviation from the built-in rules?" It also introduces an opportunity for hard-to-find mistakes: Misspelling a built-in variable silently results in an empty string.

The core of your Makefile, therefore, is a simple $(APP_NAME): $(SRC_FILE).

Source Link

answered Dec 23, 2024 at 11:19

Generally, I would use as much of the make built-ins as possible. Specifically:

I would normally not specify the C++ (or C) compiler. The default for gnu make is g++; the system should be set up to use the most adequate one — for example, through a symbolic link from g++ to the g++ du jour. Changing that compiler, which may happen at any point, should not make it necessary to touch the Makefile. An explicit compiler specification would (only) make sense for projects which have special needs like depending on a specific compiler version, or a cross compiler.
There is no need to tell gnu make how to compile and link C++ files to produce an executable. This case is so common that it is built-in: The line @$(CXX) $(CXXFLAGS) $(SRC_FILE) -o $(APP_NAME) is exactly the built-in rule. Making it explicit adds nothing except trouble for a reviewer, possibly yourself later on: "Since the author was explicit, they probably wanted to do something differently. Where is the intended deviation from the built-in rules?" It also introduces an opportunity for hard-to-find mistakes: Misspelling a built-in variable silently results in an empty string.

The core of your Makefile, therefore, is a simple $(APP_NAME): $(SRC_FILE).