4 ms·

> like make, it encourages an imperative mode for project tooling and I think we should distance ourselves from that a bit further. Um, what? `make` is arguabl

by o11c 2y ago

> like make, it encourages an imperative mode for project tooling and I think we should distance ourselves from that a bit further. Um, what? `make` is arguably the most common declarative tool in existence ... Whenever people complain about Make in detail, it's almost always either because they're violating Paul's Rules of Makefiles or because they're actually complaining about autotools (or occasionally cmake).

joshuamorton 2y ago
Make isn't, at all, declarative. It's almost entirely based on you writing out what to invoke, as opposed to what should exist and having the build system "figure that out". That is, in make you say `$(CC) -c foo.c -o foo.o`, which is telling you, ultimately, how to compile the thing, while declarative build systems (bazel/nix/etc.) you say "this is a cc_binary" or "this is a cc_library" and you let it figure the rest out for you.
- GuB-42 2y ago
  If your executable is named "foo" and there is a "foo.c" somewhere, your Makefile only needs to contain "foo:" and make will figure out how to build it using its default rules. If you have more than one file (ex: foo.c and bar.c), just write "foo: bar.c". Modern build systems are more advanced and have better defaults, but the general idea is the same. They are all declarative. An imperative build system would be like a shell script.
- o11c 2y ago
  Your "declarative" systems are no more declarative - they just hide the commands/flags being used, far worse than `include config.make`.
__MatrixMan__ 2y ago
It's quite easy to accidentally write makefiles that build something different when you run them a second time, or when some server that used to be reliable suddenly goes down. Or when the user upgrades something that you wouldn't think is related. It does no validation of inputs. So suppose you're bisecting your way towards the cause of a failure related to the compiler version. Ideally there would be a commit which changed the compiler version, so your bisect would find a nice neat boundary in version history where the problem began. Make, by contrast, is just picking up whatever it finds on the PATH and hoping for the best. So the best you can do is exclude the code as the source of the bug and start scratching your head about the environment. That willingness to just pick up whatever it finds and make changes wherever it wants with no regard to whether dependency created by these state changes is made explicit and transparent to the user is what I mean by "imperative".

by o11c 2y ago

joshuamorton 2y ago

Make isn't, at all, declarative. It's almost entirely based on you writing out what to invoke, as opposed to what should exist and having the build system "figure that out". That is, in make you say `$(CC) -c foo.c -o foo.o`, which is telling you, ultimately, how to compile the thing, while declarative build systems (bazel/nix/etc.) you say "this is a cc_binary" or "this is a cc_library" and you let it figure the rest out for you.

GuB-42 2y ago
If your executable is named "foo" and there is a "foo.c" somewhere, your Makefile only needs to contain "foo:" and make will figure out how to build it using its default rules. If you have more than one file (ex: foo.c and bar.c), just write "foo: bar.c". Modern build systems are more advanced and have better defaults, but the general idea is the same. They are all declarative. An imperative build system would be like a shell script.
o11c 2y ago
Your "declarative" systems are no more declarative - they just hide the commands/flags being used, far worse than `include config.make`.

__MatrixMan__ 2y ago

It's quite easy to accidentally write makefiles that build something different when you run them a second time, or when some server that used to be reliable suddenly goes down. Or when the user upgrades something that you wouldn't think is related. It does no validation of inputs. So suppose you're bisecting your way towards the cause of a failure related to the compiler version. Ideally there would be a commit which changed the compiler version, so your bisect would find a nice neat boundary in version history where the problem began. Make, by contrast, is just picking up whatever it finds on the PATH and hoping for the best. So the best you can do is exclude the code as the source of the bug and start scratching your head about the environment. That willingness to just pick up whatever it finds and make changes wherever it wants with no regard to whether dependency created by these state changes is made explicit and transparent to the user is what I mean by "imperative".