3 ms·

It seems weird to me to write your own build system and give advice on build systems when your basic makefile already completely violates what the manual sugges

by eska 3y ago

It seems weird to me to write your own build system and give advice on build systems when your basic makefile already completely violates what the manual suggests.

Arch-TK 3y ago
Unnecessarily vague and uncharitable comment but I'll bite. While I recommend anyone who uses GNU make should read the manual, the manual is full of outdated best practices which can be safely ignored. If I was going to use this makefile for my own project, I would even drop the clean target entirely. phony targets are mostly a misfeature. Although it looks like the makefile as accepted by the project hasn't marked the all target as phony. But go on, tell me what it is that is not recommended specifically. I am aware of many deviations from what the GNU make manual claims is recommended. A large portion of deviations is the lack of many of the standard targets it thinks should be provided. Another deviation might be the uppercase OBJS should be lowercase according to the manual, but in this case I was trying to minimize the number of immaterial changes from the original makefile I modified to arrive at this point since it was not my project.
- eska 3y ago
  No need to talk about anything advanced. Line 2 and 3 for example make it impossible to override certain behavior you’ve set. >If you are insistent on make, stick to GNU make, read the GNU make manual, understand make I refer to this authoritative sounding comment while you miss out on the very basics like that.
  - Arch-TK 3y ago
    >Line 2 and 3 for example make it impossible to override certain behavior you’ve set. This is intentional. It's not possible (unfortunately) to allow users to simultaneously be able to override a variable OR add to a variable in make. In the case of the FLAGS variables I usually prefer to append to allow users to add to the variables. As a compromise, in my own makefiles I explicitly ensure that these variables _only_ contain flags which are mandatory for the project to build correctly. In this case this was deviated from (with the warning flags, -fsanitize=address, -ggdb) because of the request of the project author. Would you rather an end user be able to quickly add LDFLAGS and CXXFLAGS or rather have the end-user have to copy the entire list of flags out of the makefile just so they can add one? I would say it's more common for someone to want to add a flag than to replace all the mandatory ones. If someone is using a sufficiently different compiler such that those flags are no longer relevant, they would likely need to modify the rest of the makefile. >I refer to this authoritative sounding comment while you miss out on the very basics like that. It's uncharitable to assume that just because you don't understand a decision someone made in something they wrote, that they must be ignorant about the tool they are using.

by eska 3y ago

It seems weird to me to write your own build system and give advice on build systems when your basic makefile already completely violates what the manual suggests.

Arch-TK 3y ago

Unnecessarily vague and uncharitable comment but I'll bite. While I recommend anyone who uses GNU make should read the manual, the manual is full of outdated best practices which can be safely ignored. If I was going to use this makefile for my own project, I would even drop the clean target entirely. phony targets are mostly a misfeature. Although it looks like the makefile as accepted by the project hasn't marked the all target as phony. But go on, tell me what it is that is not recommended specifically. I am aware of many deviations from what the GNU make manual claims is recommended. A large portion of deviations is the lack of many of the standard targets it thinks should be provided. Another deviation might be the uppercase OBJS should be lowercase according to the manual, but in this case I was trying to minimize the number of immaterial changes from the original makefile I modified to arrive at this point since it was not my project.

eska 3y ago
No need to talk about anything advanced. Line 2 and 3 for example make it impossible to override certain behavior you’ve set. >If you are insistent on make, stick to GNU make, read the GNU make manual, understand make I refer to this authoritative sounding comment while you miss out on the very basics like that.
- Arch-TK 3y ago
  >Line 2 and 3 for example make it impossible to override certain behavior you’ve set. This is intentional. It's not possible (unfortunately) to allow users to simultaneously be able to override a variable OR add to a variable in make. In the case of the FLAGS variables I usually prefer to append to allow users to add to the variables. As a compromise, in my own makefiles I explicitly ensure that these variables _only_ contain flags which are mandatory for the project to build correctly. In this case this was deviated from (with the warning flags, -fsanitize=address, -ggdb) because of the request of the project author. Would you rather an end user be able to quickly add LDFLAGS and CXXFLAGS or rather have the end-user have to copy the entire list of flags out of the makefile just so they can add one? I would say it's more common for someone to want to add a flag than to replace all the mandatory ones. If someone is using a sufficiently different compiler such that those flags are no longer relevant, they would likely need to modify the rest of the makefile. >I refer to this authoritative sounding comment while you miss out on the very basics like that. It's uncharitable to assume that just because you don't understand a decision someone made in something they wrote, that they must be ignorant about the tool they are using.