5 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

by 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/
  - crdoconnor 9y ago
    >You already memorize similiar syntax things for other languages. Yes, and cryptic configuration settings and syntax causes obscure, hard to track down bugs in other languages too. Welcome to programming. I am not saying it isn't a problem elsewhere. I'm saying that if a competing build system manages to do the same things in a less cryptic way then that's a strong point in its favor. Essentially make is a fully fledged stringly typed programming language - it's got conditionals, loops, variables, etc. It just wasn't a fully fledged turing complete programming language that had a lot of thought put in to syntax, usability and readability. By contrast, there are many languages which actually did have a lot of thought put in to those things. Btw, stringly typed is not commonly considered a 'good' thing. >Stop being lazy and read the manual. Did the fact that I commented on its quality make you think that I didn't look at it? Try doing ctrl-F on the manual and searching for ccache and cross compilation - what the OP regarded as two of the most "necessary" features. To be fair, I can find information about these things.... stack overflow has information on them. Also, if you dig deep in to the docs the amount of context given is very thin. Look at section "the two flavors of variable" - it took about 300 words to explain something that could have been illustrated with two simple examples.

by Ace17 9y ago

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/
- crdoconnor 9y ago
  >You already memorize similiar syntax things for other languages. Yes, and cryptic configuration settings and syntax causes obscure, hard to track down bugs in other languages too. Welcome to programming. I am not saying it isn't a problem elsewhere. I'm saying that if a competing build system manages to do the same things in a less cryptic way then that's a strong point in its favor. Essentially make is a fully fledged stringly typed programming language - it's got conditionals, loops, variables, etc. It just wasn't a fully fledged turing complete programming language that had a lot of thought put in to syntax, usability and readability. By contrast, there are many languages which actually did have a lot of thought put in to those things. Btw, stringly typed is not commonly considered a 'good' thing. >Stop being lazy and read the manual. Did the fact that I commented on its quality make you think that I didn't look at it? Try doing ctrl-F on the manual and searching for ccache and cross compilation - what the OP regarded as two of the most "necessary" features. To be fair, I can find information about these things.... stack overflow has information on them. Also, if you dig deep in to the docs the amount of context given is very thin. Look at section "the two flavors of variable" - it took about 300 words to explain something that could have been illustrated with two simple examples.