| > That's precisley why official/standard build systems suck, they are extremly cumbersome to wrangle when you go off the beaten path. That is the first sensible criticism I've heard in this thread. Thanks for engaging maturely and with an insight that can only come from actual experience. My counterargument is that the Make experience is cumbersome to wrangle on projects that are very much on the beaten path. But I see your point that it is flexible, i.e. it doesn't get more cumbersome if you go off the beaten path. The other caveat I'll give is that my rosy view of cargo may be in part because I haven't written a lot of Rust code. > Just let me write a build.bat/build.sh per platform/compiler/configuration that are explicit and precise in compiler flags, paths, output files, pre/post processing, etc so nothing magical is happening under the hood. I agree with this completely, and this is why I avoid what I call "configuration-oriented programming", which is where you're trying to do something that requires a programming language, but you have something like JSON /YAML/TOML instead of a programming language. But at a glance it appears to me that `cargo` can farm out to the programming language of your choice pretty easily so it doesn't feel like this critique applies. |
That's precisely why I like Make. Make lets you specify an input file, the name of an output file, and the shell commands necessary to generate the output file from the input file. You have the full power of the shell at your disposal which means you can farm out to core utils, Python, or whatever else suits your fancy.
I not only use Make for compiling C code, but also for compiling my websites (run "go build", minify assets, etc). You could use Make to invoke rustc if you wanted. Make is composable by design. In my opinion it _is_ a scalable build system.