4 ms·

>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

>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.
  - lolikoisuru 9y ago
    >It just wasn't a fully fledged turing complete programming language It is turing complete though.
Ace17 9y ago
> I can envisage other projects doing a better job than make on its home turf. Of course it's possible, GNU make is far from being perfect ; it's a pity we can't slowly evolve the language for backward compatibility reasons. Autotools also are far from being perfect. - As a project author, I like writing custom simple makefiles and hate anything related to editing "autoconf.ac". - As a package manager, I love projects using autoconf (or exposing autoconf's options, such as --host): they're the easiest to build because they all have the same "build interface" (alas, by default, there's no equivalent to "./configure --host" for cmake). And I despise projects using "custom simple makefiles", because it means that I'm going to have to learn yet another parochialistic BS (for build system) and have yet another special case for this specific project. Maybe one day we will have a build system that's loved by both sides? :-)
- crdoconnor 9y ago
  I think the ideal build tool would be a framework written in a decent, readable high level scripting language.

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.
- lolikoisuru 9y ago
  >It just wasn't a fully fledged turing complete programming language It is turing complete though.

Ace17 9y ago

> I can envisage other projects doing a better job than make on its home turf. Of course it's possible, GNU make is far from being perfect ; it's a pity we can't slowly evolve the language for backward compatibility reasons. Autotools also are far from being perfect. - As a project author, I like writing custom simple makefiles and hate anything related to editing "autoconf.ac". - As a package manager, I love projects using autoconf (or exposing autoconf's options, such as --host): they're the easiest to build because they all have the same "build interface" (alas, by default, there's no equivalent to "./configure --host" for cmake). And I despise projects using "custom simple makefiles", because it means that I'm going to have to learn yet another parochialistic BS (for build system) and have yet another special case for this specific project. Maybe one day we will have a build system that's loved by both sides? :-)

crdoconnor 9y ago
I think the ideal build tool would be a framework written in a decent, readable high level scripting language.