4 ms·

TBH I don't have many fond memories of open-source build systems. Any widely used build system (that probably <10% of the developers know very well, anyway) is

TBH I don't have many fond memories of open-source build systems. Any widely used build system (that probably <10% of the developers know very well, anyway) is not going to help if the build realized with it is broken (too flexible, too confusing, too optimistic about others' environments). And frankly most uses of those build systems in the wild are "give up control and pray". 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. And the build script just needs to be run. It takes no arguments, so I don't think there is a problem with that.

rout39574 9y ago
I think that your build would be much more readable as make. Building object code and libraries from C is.. kind of well traveled ground? Making an idiosyncratic system is satisfying, but the usefulness of your work is decreased if it's decorated with locally invented barriers to comprehension. Rock on; scratch your itches.
- jstimpfle 9y ago
  I don't entirely disagree. If you only compile C files this is not for you. This is about exploring what building blocks it takes to also support building all the custom things you need besides that in a larger project.
Ace17 9y ago
> 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. This misses the point IMHO. In practice, whatever complex the build system is, it's generally easy to add a new source file: simply grep for an existing source file name, find the build files that refers to it, and insert a similar line for your new file. > And the build script just needs to be run. It takes no arguments, so I don't think there is a problem with that. What about: cross compilation? ccache injection? verbose builds? parallelism control? installation prefix? Try being a package maintainer for a GNU/Linux distribution, where all of the above needs to be kept under control. You will despise custom build systems. Established build systems (like GNU Autoconf (e.g gcc), and, to some extent, custom Autoconf (ffmpeg, libvpx)) handle all these cases pretty well, and provide fixed commande-line options (--prefix, --host) to control them. This means the project author doesn't get to decide how the option will be named and how it will work. This make a huge difference if you're trying to packages for your distrib dozens of projects from dozens of various authors. With a custom build system, the best case scenario is you have to re-learn all these options for each project. The worst case scenario is: one project doesn't support some use case (e.g cross-compiling), so you have to maintain a patch that hacks into the build files to add the behavior your need.
- lolikoisuru 9y ago
  >What about: cross compilation? ccache injection? verbose builds? parallelism control? installation prefix? Try being a package maintainer for a GNU/Linux distribution, where all of the above needs to be kept under control. You will despise custom build systems. None of those are features that developers care about. They are only of interest to package maintainers, systems administrators and other lunatics.
  - pleasecalllater 9y ago
    Yea... how come that "I don't care" became a virtue.
    - oblio 9y ago
      It's not a virtue, but it is what happens in real life, though. And I'm one of those "lunatics".
- crdoconnor 9y ago
  >With a custom build system, the best case scenario is you have to re-learn all these options for each project. The best case scenario would be that it handles all of those scenarios in A) a highly readable way and B) has high quality documentation that demonstrates the use of all the necessary features in context. Make's approach appears to be to use cryptic flags and settings and the best case documentation appears to be "have you tried stack overflow?". It is not the be all and end all of build systems. Additionally, for many of the non-C++ workflows I want to accommodate, the 'make' approach appears to be hack around its deficiencies with bash scripting. Stringing together hacky bash scripts is not what I would describe as a best case scenario in any project. I don't think of this guy's project is a meaningful competitor to make/cmake but equally, I can envisage other projects doing a better job than make on its home turf.
  - lolikoisuru 9y ago
    > Make's approach appears to be to use cryptic flags and settings You already memorize similiar syntax things for other languages. Why is it so hard to accept in this case? Comparatively there are a lot less of them to remember with make as well. Stop being lazy and read the manual. > and the best case documentation appears to be "have you tried stack overflow?". Make's documentation is fantastic. The manual is very comprehensive and well written. Just because you're too lazy to read a manual doesn't mean there isn't documentation. Go read the documentation for make: https://gnu.org/s/make/manual/ https://gnu.org/s/make/manual/
lolikoisuru 9y ago
>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.

rout39574 9y ago

I think that your build would be much more readable as make. Building object code and libraries from C is.. kind of well traveled ground? Making an idiosyncratic system is satisfying, but the usefulness of your work is decreased if it's decorated with locally invented barriers to comprehension. Rock on; scratch your itches.

jstimpfle 9y ago
I don't entirely disagree. If you only compile C files this is not for you. This is about exploring what building blocks it takes to also support building all the custom things you need besides that in a larger project.

Ace17 9y ago

> 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. This misses the point IMHO. In practice, whatever complex the build system is, it's generally easy to add a new source file: simply grep for an existing source file name, find the build files that refers to it, and insert a similar line for your new file. > And the build script just needs to be run. It takes no arguments, so I don't think there is a problem with that. What about: cross compilation? ccache injection? verbose builds? parallelism control? installation prefix? Try being a package maintainer for a GNU/Linux distribution, where all of the above needs to be kept under control. You will despise custom build systems. Established build systems (like GNU Autoconf (e.g gcc), and, to some extent, custom Autoconf (ffmpeg, libvpx)) handle all these cases pretty well, and provide fixed commande-line options (--prefix, --host) to control them. This means the project author doesn't get to decide how the option will be named and how it will work. This make a huge difference if you're trying to packages for your distrib dozens of projects from dozens of various authors. With a custom build system, the best case scenario is you have to re-learn all these options for each project. The worst case scenario is: one project doesn't support some use case (e.g cross-compiling), so you have to maintain a patch that hacks into the build files to add the behavior your need.

lolikoisuru 9y ago
>What about: cross compilation? ccache injection? verbose builds? parallelism control? installation prefix? Try being a package maintainer for a GNU/Linux distribution, where all of the above needs to be kept under control. You will despise custom build systems. None of those are features that developers care about. They are only of interest to package maintainers, systems administrators and other lunatics.
- pleasecalllater 9y ago
  Yea... how come that "I don't care" became a virtue.
  - oblio 9y ago
    It's not a virtue, but it is what happens in real life, though. And I'm one of those "lunatics".
crdoconnor 9y ago
>With a custom build system, the best case scenario is you have to re-learn all these options for each project. The best case scenario would be that it handles all of those scenarios in A) a highly readable way and B) has high quality documentation that demonstrates the use of all the necessary features in context. Make's approach appears to be to use cryptic flags and settings and the best case documentation appears to be "have you tried stack overflow?". It is not the be all and end all of build systems. Additionally, for many of the non-C++ workflows I want to accommodate, the 'make' approach appears to be hack around its deficiencies with bash scripting. Stringing together hacky bash scripts is not what I would describe as a best case scenario in any project. I don't think of this guy's project is a meaningful competitor to make/cmake but equally, I can envisage other projects doing a better job than make on its home turf.
- lolikoisuru 9y ago
  > Make's approach appears to be to use cryptic flags and settings You already memorize similiar syntax things for other languages. Why is it so hard to accept in this case? Comparatively there are a lot less of them to remember with make as well. Stop being lazy and read the manual. > and the best case documentation appears to be "have you tried stack overflow?". Make's documentation is fantastic. The manual is very comprehensive and well written. Just because you're too lazy to read a manual doesn't mean there isn't documentation. Go read the documentation for make: https://gnu.org/s/make/manual/ https://gnu.org/s/make/manual/

lolikoisuru 9y ago

>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.