7 ms·

This (among other reasons) is why I'm moving a few of my C projects over to Rust. Whenever I'm spending a half hour debugging why my build system isn't picking

This (among other reasons) is why I'm moving a few of my C projects over to Rust. Whenever I'm spending a half hour debugging why my build system isn't picking up some file or some flag is getting passed wrong, I end up asking myself, "Why am I doing this?" My entire build system in Rust projects consists of the commands "cargo build", "cargo run", and "cargo test" and I have yet to find a reason to deviate from the default filesystem structure or configurations. To be clear there are real reasons to still be writing C. No hate to the author of this post. I just don't want to be doing it any more in most cases.

colonwqbang 3y ago
Your problems are not with C the language but with the chosen build tools. Have you tried using a more modern tool like Meson? It is more comparable to Cargo. To start a new project today using plain GNU Make like the author of the article recommends, is not a good idea unless you enjoy fiddling with the build.
- flykespice 3y ago
  > Have you tried using a more modern tool like Meson? It is more comparable to Cargo. Not comparable at all. The difference is Cargo is the official standard package manager of the Rust language. Meson is one among the sea of incompatible build systems for the C language.
  - binary132 3y ago
    That's why we need a new build system / package manager for C. /s (but not really)
    - funnyflywheel 3y ago
      https://xkcd.com/927 https://xkcd.com/927 comes to mind.
      - binary132 3y ago
        Yeah, that's the joke. But I mean, you have to admit the status quo isn't that good. Something really very much better might be able to claw its way to the top.
      - keybored 3y ago
        Please perish the thought.
  - tialaramex 3y ago
    Right, crucially cargo is in the box with your Rust compiler, you have to go out of your way to have just the actual Rust compiler but not cargo. As with the lesson gofmt taught, you must supply the basic feature in the box. Humans are lazy, so if it doesn't come in the box only people who know they can't live without it will even bother, put it in the box and only people who can't live with it will remove it.
  - humanrebar 3y ago
    But C ships to all sorts of places, so why would C limit its options by limiting its support to its own package manager?
    - kerkeslager 3y ago
      How would having a builtin build system (I'm not even asking for a package manager) limit where C can ship to?
- jjgreen 3y ago
  With make, you don't have to install anything, it's POSIX
  - yjftsjthsd-h 3y ago
    Being POSIX doesn't mean it's included by default; for example, you can start with the default installation of debian, install a compiler, and still not have make installed
  - kerkeslager 3y ago
    This technically isn't true, but I'll give you the point because I don't see `sudo apt install build-essentials` as a significant barrier to entry. But being able to print "make: ** No targets specified and no makefile found. Stop." to stderr isn't particularly useful, and having to write a Makefile is a significant barrier.
- kerkeslager 3y ago
  > Your problems are not with C the language but with the chosen build tools. That's not a distinction I care about. The tooling around a language should be a part of discussing the merits of a language. Your language can be the most ergonomic language in the world, but if all your development gains are lost fiddling with build tools, you haven't gained anything. > Have you tried using a more modern tool like Meson? I haven't, but now that I know about it, I'll give it a try. Thanks for the info! It looks promising. > To start a new project today using plain GNU Make like the author of the article recommends, is not a good idea unless you enjoy fiddling with the build. Maybe, but that just brings up the problem that there isn't really a clear second-tier system outside the standard library for tools. Certain tools (i.e. Valgrind) are well-known, but there are a million different ways to install a million different tools and for most things it's ultimately more common to just roll your own.
nanolith 3y ago
It is true that C does not have a single tool enforced by the language platform. But, there is plenty of excellent documentation available for using build and packaging tools of your choice to work similarly to Cargo.
- jerf 3y ago
  In practice this comes off as a rather motte and bailey argument. "There's plenty of ways to make building C as easy as Cargo." OK, show me. "Well, you use this and do this and this." OK, that didn't work because of $THIS_REASON. "Oh that's easy to fix you just do this thing." {Repeat several times.} OK, I guess it's working now, but there's no way that was as easy as cargo. "What are you talking about, it was a series of easy steps that only involved reading dozens of pages of docs, a couple of not-quite-current-but-close-to-accurate Stack Overflow posts, upgrading to the correct version of the build tool, and directly posting on a couple of mailing lists!" To be honest, the moment I have to evaluate a dozen tools, pick one, and use it, even if that tool does manage to be "$TOOL build" and literally nothing else which I don't think is anywhere near something people can count on in the C world, it has already proved to be harder than "cargo build".
  - norir 3y ago
    There is a price to easy. In my experience, cargo build times tend to be soulkillingly long. But I don't like waiting more than a few hundred ms for incremental builds. So for me, cargo build is actually harder than make to attain an enjoyable build system. Make is annoying but Makefile issues are found quickly and easily when running `find . | entr -c make` and saving the source file often.
    - alpaca128 3y ago
      Build times have nothing to do with cargo but with the language itself. They're not the "price to easy", it's the price of the static compiler checks.
      - 3y ago
lelanthran 3y ago
Every C discussion on the net always gets derailed by Rust proselytising. No other language community does this to other language discussion. Even C++ fanatics didn't do this back when C++ was being sold as a C replacement. This is an entirely new and somewhat sad, phenomenon: the need for the rust community to derail any and all discussion about some other language reeks of a community that feels threatened.
- twic 3y ago
  The comment you're responding to wasn't written by "the rust community", it was written by kerkeslager, who has written a bunch of C programs, but has found that the Rust build tools are better. There is nothing new or sad about it.
  - lelanthran 3y ago
    > The comment you're responding to wasn't written by "the rust community" This makes no sense. Almost by definition, anyone derailing a discussion to mention $FOO is a member of the $FOO community. It's disingenuous to suggest that all derailment is due to non-$FOO advocates. > There is nothing new or sad about it. The phenomenon of persistent derailment is, in fact, something that I had not seen until Rust arrived. It is new, it's limited only to Rust advocates as a group, and I find it sad.
    - jcranmer 3y ago
      > The phenomenon of persistent derailment is, in fact, something that I had not seen until Rust arrived. Apparently you have never seen a thread on X11, which almost invariably is derailed by a discussion about Wayland. Or in general, any discussion on Wayland or systemd is derailed into a rant how they're the worst software ever developed or something, to a tedious degree that makes me long for the Rewrite-it-in-Rust comments because at least those sometime make compelling points.
    - lelandbatey 3y ago
      I also find that Go has delightful build tooling; running 'go build ./...' is nearly the universal build tool. There, now we're not limited to just Rust advocates, so I hope you no longer find this thread sad : )
jvanderbot 3y ago
I have the same problem with Rust modules: e.g., where do I put crate::, vs module X, vs module X{ } again? Do I have to specify it in the automatic lib.rs too? Or ... C at least lives on the filesystem and you tell it where to grab things.
- treyd 3y ago
  Module definitions in Rust have simple rules that resolve `mod foo;` into foo.rs or foo/mod.rs, which lives in the filesystem layout just as it does in C, you just don't have to use quotes and it has to form a tree from a root module at lib.rs. If you want to be even more explicit about it there's an attribute you can put on a `mod` item to override the normal path resolution rules.
- kerkeslager 3y ago
  > e.g., where do I put crate::, vs module X, vs module X{ } again? Do I have to specify it in the automatic lib.rs too? Sure, but there's one clear answer to that question which you can refresh your memory of in under 3 minutes of reading. C does live in the filesystem, but where in the filesystem? Oh and it doesn't always live in the filesystem--sometimes it lives in the package system.
cmovq 3y ago
I don’t understand why people bother with complex build systems for small C projects. Here is a C build system: cat all.c #include "foo.c" #include "bar.c" #include "main.c" clang all.c
- eschneider 3y ago
  #include "/dev/tty0" so you can add run-time defines.
- humanrebar 3y ago
  Now add an address sanitizer pass, reasonable unit tests, and wire it up to CI so you don't accidentally break things or trash memory.
- kerkeslager 3y ago
  Sure, trivial problems only require trivial solutions. Obviously. But I don't want to solve trivial problems. That's not where the value is.
hgs3 3y ago
> "cargo build", "cargo run", and "cargo test" What about "gcc mycode.c" or "make"? You shouldn't need to reinvent your build system every project.
- kerkeslager 3y ago
  `gcc mycode.c` has to be some sort of joke you're making. I'm not trying to compile "Hello, world" in C, I'm writing C code that will be run in production to solve real-world problems. For projects of any significant size, you're going to run into some constraint which requires you to use `make` differently than you have before.
  - cantours 3y ago
    >For projects of any significant size, you're going to run into some constraint which requires you to use `make` differently than you have before. That's precisley why official/standard build systems suck, they are extremly cumbersome to wrangle when you go off the beaten path. So the irony is that standard build systems/package manager are whats good for hello worlds, non-trivial programs require custom build steps. 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.
    - kerkeslager 3y ago
      > 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.

colonwqbang 3y ago

Your problems are not with C the language but with the chosen build tools. Have you tried using a more modern tool like Meson? It is more comparable to Cargo. To start a new project today using plain GNU Make like the author of the article recommends, is not a good idea unless you enjoy fiddling with the build.

flykespice 3y ago
> Have you tried using a more modern tool like Meson? It is more comparable to Cargo. Not comparable at all. The difference is Cargo is the official standard package manager of the Rust language. Meson is one among the sea of incompatible build systems for the C language.
- binary132 3y ago
  That's why we need a new build system / package manager for C. /s (but not really)
  - funnyflywheel 3y ago
    https://xkcd.com/927 https://xkcd.com/927 comes to mind.
    - binary132 3y ago
      Yeah, that's the joke. But I mean, you have to admit the status quo isn't that good. Something really very much better might be able to claw its way to the top.
    - keybored 3y ago
      Please perish the thought.
- tialaramex 3y ago
  Right, crucially cargo is in the box with your Rust compiler, you have to go out of your way to have just the actual Rust compiler but not cargo. As with the lesson gofmt taught, you must supply the basic feature in the box. Humans are lazy, so if it doesn't come in the box only people who know they can't live without it will even bother, put it in the box and only people who can't live with it will remove it.
- humanrebar 3y ago
  But C ships to all sorts of places, so why would C limit its options by limiting its support to its own package manager?
  - kerkeslager 3y ago
    How would having a builtin build system (I'm not even asking for a package manager) limit where C can ship to?
jjgreen 3y ago
With make, you don't have to install anything, it's POSIX
- yjftsjthsd-h 3y ago
  Being POSIX doesn't mean it's included by default; for example, you can start with the default installation of debian, install a compiler, and still not have make installed
- kerkeslager 3y ago
  This technically isn't true, but I'll give you the point because I don't see `sudo apt install build-essentials` as a significant barrier to entry. But being able to print "make: ** No targets specified and no makefile found. Stop." to stderr isn't particularly useful, and having to write a Makefile is a significant barrier.
kerkeslager 3y ago
> Your problems are not with C the language but with the chosen build tools. That's not a distinction I care about. The tooling around a language should be a part of discussing the merits of a language. Your language can be the most ergonomic language in the world, but if all your development gains are lost fiddling with build tools, you haven't gained anything. > Have you tried using a more modern tool like Meson? I haven't, but now that I know about it, I'll give it a try. Thanks for the info! It looks promising. > To start a new project today using plain GNU Make like the author of the article recommends, is not a good idea unless you enjoy fiddling with the build. Maybe, but that just brings up the problem that there isn't really a clear second-tier system outside the standard library for tools. Certain tools (i.e. Valgrind) are well-known, but there are a million different ways to install a million different tools and for most things it's ultimately more common to just roll your own.

nanolith 3y ago

It is true that C does not have a single tool enforced by the language platform. But, there is plenty of excellent documentation available for using build and packaging tools of your choice to work similarly to Cargo.

jerf 3y ago
In practice this comes off as a rather motte and bailey argument. "There's plenty of ways to make building C as easy as Cargo." OK, show me. "Well, you use this and do this and this." OK, that didn't work because of $THIS_REASON. "Oh that's easy to fix you just do this thing." {Repeat several times.} OK, I guess it's working now, but there's no way that was as easy as cargo. "What are you talking about, it was a series of easy steps that only involved reading dozens of pages of docs, a couple of not-quite-current-but-close-to-accurate Stack Overflow posts, upgrading to the correct version of the build tool, and directly posting on a couple of mailing lists!" To be honest, the moment I have to evaluate a dozen tools, pick one, and use it, even if that tool does manage to be "$TOOL build" and literally nothing else which I don't think is anywhere near something people can count on in the C world, it has already proved to be harder than "cargo build".
- norir 3y ago
  There is a price to easy. In my experience, cargo build times tend to be soulkillingly long. But I don't like waiting more than a few hundred ms for incremental builds. So for me, cargo build is actually harder than make to attain an enjoyable build system. Make is annoying but Makefile issues are found quickly and easily when running `find . | entr -c make` and saving the source file often.
  - alpaca128 3y ago
    Build times have nothing to do with cargo but with the language itself. They're not the "price to easy", it's the price of the static compiler checks.
    - 3y ago

lelanthran 3y ago

Every C discussion on the net always gets derailed by Rust proselytising. No other language community does this to other language discussion. Even C++ fanatics didn't do this back when C++ was being sold as a C replacement. This is an entirely new and somewhat sad, phenomenon: the need for the rust community to derail any and all discussion about some other language reeks of a community that feels threatened.

twic 3y ago
The comment you're responding to wasn't written by "the rust community", it was written by kerkeslager, who has written a bunch of C programs, but has found that the Rust build tools are better. There is nothing new or sad about it.
- lelanthran 3y ago
  > The comment you're responding to wasn't written by "the rust community" This makes no sense. Almost by definition, anyone derailing a discussion to mention $FOO is a member of the $FOO community. It's disingenuous to suggest that all derailment is due to non-$FOO advocates. > There is nothing new or sad about it. The phenomenon of persistent derailment is, in fact, something that I had not seen until Rust arrived. It is new, it's limited only to Rust advocates as a group, and I find it sad.
  - jcranmer 3y ago
    > The phenomenon of persistent derailment is, in fact, something that I had not seen until Rust arrived. Apparently you have never seen a thread on X11, which almost invariably is derailed by a discussion about Wayland. Or in general, any discussion on Wayland or systemd is derailed into a rant how they're the worst software ever developed or something, to a tedious degree that makes me long for the Rewrite-it-in-Rust comments because at least those sometime make compelling points.
  - lelandbatey 3y ago
    I also find that Go has delightful build tooling; running 'go build ./...' is nearly the universal build tool. There, now we're not limited to just Rust advocates, so I hope you no longer find this thread sad : )

jvanderbot 3y ago

I have the same problem with Rust modules: e.g., where do I put crate::, vs module X, vs module X{ } again? Do I have to specify it in the automatic lib.rs too? Or ... C at least lives on the filesystem and you tell it where to grab things.

treyd 3y ago
Module definitions in Rust have simple rules that resolve `mod foo;` into foo.rs or foo/mod.rs, which lives in the filesystem layout just as it does in C, you just don't have to use quotes and it has to form a tree from a root module at lib.rs. If you want to be even more explicit about it there's an attribute you can put on a `mod` item to override the normal path resolution rules.
kerkeslager 3y ago
> e.g., where do I put crate::, vs module X, vs module X{ } again? Do I have to specify it in the automatic lib.rs too? Sure, but there's one clear answer to that question which you can refresh your memory of in under 3 minutes of reading. C does live in the filesystem, but where in the filesystem? Oh and it doesn't always live in the filesystem--sometimes it lives in the package system.

cmovq 3y ago

I don’t understand why people bother with complex build systems for small C projects. Here is a C build system: cat all.c #include "foo.c" #include "bar.c" #include "main.c" clang all.c

eschneider 3y ago
#include "/dev/tty0" so you can add run-time defines.
humanrebar 3y ago
Now add an address sanitizer pass, reasonable unit tests, and wire it up to CI so you don't accidentally break things or trash memory.
kerkeslager 3y ago
Sure, trivial problems only require trivial solutions. Obviously. But I don't want to solve trivial problems. That's not where the value is.

hgs3 3y ago

> "cargo build", "cargo run", and "cargo test" What about "gcc mycode.c" or "make"? You shouldn't need to reinvent your build system every project.

kerkeslager 3y ago
`gcc mycode.c` has to be some sort of joke you're making. I'm not trying to compile "Hello, world" in C, I'm writing C code that will be run in production to solve real-world problems. For projects of any significant size, you're going to run into some constraint which requires you to use `make` differently than you have before.
- cantours 3y ago
  >For projects of any significant size, you're going to run into some constraint which requires you to use `make` differently than you have before. That's precisley why official/standard build systems suck, they are extremly cumbersome to wrangle when you go off the beaten path. So the irony is that standard build systems/package manager are whats good for hello worlds, non-trivial programs require custom build steps. 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.
  - kerkeslager 3y ago
    > 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.