3 ms·

I think one reason is because Make is built with Shell, which is always one step (and one letter) away from hell. For example: clean: rm -rf *o h

by BoppreH 13y ago

I think one reason is because Make is built with Shell, which is always one step (and one letter) away from hell. For example: clean: rm -rf *o hello Did you really mean to erase all files and directories that end in "o"? Let's say it's just a typo and fix it: "*.o". Now, are you sure it'll handle files with spaces in the name? What about dashes, brackets and asterisks? Accents? What if a directory ends in .o? Hidden files? This specific case may support all of the above. But if it doesn't, what will happen? How long until you notice, and how long still to diagnose the problem? Just like I prefer static strong typing when developing non-trivial projects, the build system should be more structured. I agree endless reinventing is tiring, but it may have some credit in this case.

idlewan 13y ago
I'd expect all developers using make to know about this and never have this problem thanks to one simple thing: sticking with sensible names (no spaces, no brackets, no stars and other special characters in the name - hello underscores!). It's an easy rule. Just like I prefer static strong typing... You probably don't use any special chars or spaces for identifiers in whatever the language you're programming in. This is just applying a similar rule to the files of your project.
- BoppreH 13y ago
  For source code files I agree completely; but the build system will encounter other types of files that aren't so strict. Maybe you downloaded something and it came with a bracket because that was in the page title. Or you copied a duplicated file and your system helpfully appended " (2)" at the end. Or there was an excel file updated by someone not so technical and this person didn't know they have to strip accents from the words in their native language (possibly losing meaning). Or someone saved their "Untitled Document.txt". Or you needed to include a date in the directory name. Or you are just human and didn't mean to break the build by pressing the biggest button on your keyboard when saving a file. And remember "break the build" here is not "a red light flashes and you get an email". It means you get unknown behavior throughout the process, including security features and file removal. Strict rules for source code file names are good because names usually bleed into the language itself. Python file names become identifiers when you import them. Identifiers in turn are strict because parsing is strict, and there are many good reasons for strict parsing in general purpose languages. Lacking accent support in file names, as some very popular software do, is terrible. Lacking support for spaces is just atrocious. I love shell, I use it daily for one-off tasks, but I don't think it's a good fit to manage the build system of a project.

by BoppreH 13y ago

idlewan 13y ago

I'd expect all developers using make to know about this and never have this problem thanks to one simple thing: sticking with sensible names (no spaces, no brackets, no stars and other special characters in the name - hello underscores!). It's an easy rule. Just like I prefer static strong typing... You probably don't use any special chars or spaces for identifiers in whatever the language you're programming in. This is just applying a similar rule to the files of your project.

BoppreH 13y ago
For source code files I agree completely; but the build system will encounter other types of files that aren't so strict. Maybe you downloaded something and it came with a bracket because that was in the page title. Or you copied a duplicated file and your system helpfully appended " (2)" at the end. Or there was an excel file updated by someone not so technical and this person didn't know they have to strip accents from the words in their native language (possibly losing meaning). Or someone saved their "Untitled Document.txt". Or you needed to include a date in the directory name. Or you are just human and didn't mean to break the build by pressing the biggest button on your keyboard when saving a file. And remember "break the build" here is not "a red light flashes and you get an email". It means you get unknown behavior throughout the process, including security features and file removal. Strict rules for source code file names are good because names usually bleed into the language itself. Python file names become identifiers when you import them. Identifiers in turn are strict because parsing is strict, and there are many good reasons for strict parsing in general purpose languages. Lacking accent support in file names, as some very popular software do, is terrible. Lacking support for spaces is just atrocious. I love shell, I use it daily for one-off tasks, but I don't think it's a good fit to manage the build system of a project.