4 ms·

>If it's about making it easy for uninitiated collaborators to add new source files, then the listed build description format is pretty self-explanatory to use.

>If it's about making it easy for uninitiated collaborators to add new source files, then the listed build description format is pretty self-explanatory to use. If you write a generic makefile the uninitiated collaborator doesn't have to do anything to add new source files.

jstimpfle 9y ago
You can setup any build that way (no need to use Make) but I don't think that's a good idea.
- MereInterest 9y ago
  I'd be interested to hear what you think that way. In my mind, if a file exists within the src directory but is not compiled as part of the project, its existence is lying to the developer. Keeping a separate list of files to be included makes it possible to lie to the developer. Therefore, wildcard builds should be used, so the list of files in the src directory and the list of files being compiled are one and the same.
  - jstimpfle 9y ago
    I like to have an official place where the build rules and artifacts are clearly laid out. I don't think file system directories are a good place to put the truth. For one thing, parsing the information from the directory contents means relying on out-of-band data. For another, directories often contain files that "should not be there". Or maybe you accidentally delete an important file. The build couldn't detect the mistake.
imtringued 9y ago
That's the problem with make and why there are so many build systems built on top of it. Make alone isn't enough. It actually doesn't handle this case at all unless you use a compiler (-MMD) or any other external tool to basically generate the makefile. Otherwise you have to manage the source files and header dependencies yourself.
- lolikoisuru 9y ago
  It's out of scope for any general purpose DAG runner. Sure you can make a tool that can do that for language X, but make is used with a lot more than that. Make should not implement parsing of source code to find out what they include.

jstimpfle 9y ago

You can setup any build that way (no need to use Make) but I don't think that's a good idea.

MereInterest 9y ago
I'd be interested to hear what you think that way. In my mind, if a file exists within the src directory but is not compiled as part of the project, its existence is lying to the developer. Keeping a separate list of files to be included makes it possible to lie to the developer. Therefore, wildcard builds should be used, so the list of files in the src directory and the list of files being compiled are one and the same.
- jstimpfle 9y ago
  I like to have an official place where the build rules and artifacts are clearly laid out. I don't think file system directories are a good place to put the truth. For one thing, parsing the information from the directory contents means relying on out-of-band data. For another, directories often contain files that "should not be there". Or maybe you accidentally delete an important file. The build couldn't detect the mistake.

imtringued 9y ago

That's the problem with make and why there are so many build systems built on top of it. Make alone isn't enough. It actually doesn't handle this case at all unless you use a compiler (-MMD) or any other external tool to basically generate the makefile. Otherwise you have to manage the source files and header dependencies yourself.

lolikoisuru 9y ago
It's out of scope for any general purpose DAG runner. Sure you can make a tool that can do that for language X, but make is used with a lot more than that. Make should not implement parsing of source code to find out what they include.