20 ms·

A Modern C Development Environment

239 points by 5ADBEEF 3y ago

anotherhue 3y ago
Also see: Make Zig Your C/C++ Build System https://zig.news/kristoff/make-zig-your-c-c-build-system-28g5 https://zig.news/kristoff/make-zig-your-c-c-build-system-28g... Edit: this is a better demo (thanks jmull) https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...
- david2ndaccount 3y ago
  Doesn’t seem to offer much over just using clang.
  - jmull 3y ago
    Here's some more info why you might use this instead of plain clang. https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...
  - klardotsh 3y ago
    Other than the complete lack of writing CMake, Makefiles, autoconf, or any number of other end-user-configuration complicated systems as such, and other than the trivial statically-linked cross-compilation support, sure, I guess it's "just" a wrapper around clang, if you squint.
    - david2ndaccount 3y ago
      If you aren’t supporting more than one compiler, almost all of those tools vanish. You can just use clang.
      - klardotsh 3y ago
        If you aren't supporting more than one compiler, aren't needing to compile anything in parallel, aren't needing to find and link shared libraries on the system, aren't needing to deal with any number of real complexities that happen when building C software, then sure, build.sh calling clang a few times manually is absolutely reasonable. (And again: cross-compilation is a real concern: shipping for amd64 only is not enough in 2023). And to be clear - there are plenty of small-scale projects that fit this description! But to simply hand-wave away `zig build` or other modernized build systems and say "just use clang directly" seems a bit dishonest or incomplete to me.
        david2ndaccount 3y ago
        Note that I am not advocating for just having a few shell scripts that invoke clang. The context is someone saying to use `zig build`, and linking a blog post where all they do is compile redis from scratch, including all dependencies from source except for libc. In that context, `zig build` is just a wrapper around clang. Nowhere in their comment or linked blog post is the issue of these real complexities you allude to addressed at all. Now I personally would rather not use a pre 1.0 release of an entirely different programming language to compile my C projects instead of a cross-platform C compiler, but people can do whatever they want.
      - reverius42 3y ago
        Or more than one operating system, or more than one stdlib, etc., etc.
      - convolvatron 3y ago
        to be fair - my goto move on a smallish project when autoconf barfs is 'cc *.c -o foo'. it works pretty damn often, sometimes you need to throw in some -I action
    - rewmie 3y ago
      > or any number of other end-user-configuration complicated systems as such If you think that cmake is complicated, when in reality all it does is set targets using a declarative stye, then programming might not be for you.
      - klardotsh 3y ago
        Personal attacks are pretty unnecessary here, thanks. This kind of comment is what gives (some) C developers the reputation they have in some circles, I guess.
      - duped 3y ago
        > when in reality all it does is set targets using a declarative stye That's like the hello world of cmake builds Bigger cmake builds are doing dependency resolution, configuration tests, and configuration for development or release builds/installs. Go poke at the cmake logs and result artifacts in Debug/Release build types and see if it's "just declaring targets."
        rewmie 3y ago
        > Bigger cmake builds are doing dependency resolution, find_package(foo) #... target_link_libraries(myapp foo::Static) > configuration tests, I don't know what you mean by configuration tests. I don't think I ever added any test resembling that description other than sanity checks in cmake find modules and sanity checks on projects just for convenience. > and configuration for development or release builds Those are not handled by cmake other than setting a flag that's used in the code. > /installs. You don't need to do anything other than setting the install target. https://cmake.org/cmake/help/latest/command/install.html https://cmake.org/cmake/help/latest/command/install.html I think you're either wildly exaggerating or you've been creating your own problems.
        duped 3y ago
        Ok. How does find_package work? Hint: you need to understand how cmake module paths are discovered and their precedence, and you'll probably see a cmake folder in a build with the actual logic behind it as a .cmake file for each dependency. Depending on what package manager you're using you may not need this, or if you support many you'll need to own it. > I don't know what you mean by configuration tests. When you run cmake -S <my project> -B build folder you'll see a bunch of output. What this output corresponds to may include a number of tests that either succeed or fail to indicate whether the project will build. For example, the aforementioned find_package logic, finding the compiler tool chain (especially if cross compiling), testing for random shit like endianness, etc. > Those are not handled by cmake other than setting a flag that's used in the code. if(STREQ ${CMAKE_BUILD_TYPE} Release) .... endif() Is ridiculously common with the "..." filled in by various things like setting optimization flags, paths within the build directory, etc > You don't need to do anything other than setting the install target. No but you should probably understand what RPATH is and why it's set in release builds but not installed artifacts or why doing something that seems obvious like checking the checksum of your built object is the same as the installed one might fail. The point is that cmake does a lot of work and it's not just declaring targets. Builds are hard.
    - schemescape 3y ago
      Out of curiosity, what DO you write instead of Makefiles in this case? I’m genuinely curious if it’s actually easier, but I’m assuming you’re just using a different tool, maybe without as much historical baggage (and incompatible implementations)…
- gkfasdfasdf 3y ago
  I thought zig was removing 'zig cc' support?
  - ttrei 3y ago
    Not really: https://github.com/ziglang/zig/issues/16270#issuecomment-1616115039 https://github.com/ziglang/zig/issues/16270#issuecomment-161...
    - gkfasdfasdf 3y ago
      That's good to know, thanks
ryan-c 3y ago
At the risk of being featured in a future episode of "Hacker News reacts to (Dropbox|iPhone)"... ...a Makefile and vim (or emacs, or even nano, I'm not going to judge your kink) are fine. If they are not fine, then C is probably not the right language for the project.
- hot_gril 3y ago
  My last project in C had a CMake file that generated a Makefile, idk if you consider that too much.
- Aurornis 3y ago
  > If they are not fine, then C is probably not the right language for the project. This is called gatekeeping and it’s not helpful. It’s fine to write C in vim/emacs/nano if you want. It’s fine to write C in Visual Studio Code if you want. It’s fine to write C in CLion if you want. There is nothing wrong with any approach and no need to gatekeeper an entire programming language based on editor preference.
  - the-printer 3y ago
    Is it really gatekeeping? Does this opinion (that was valid and useful to me) carry any preventive force that the term suggests?
    - bryancoxwell 3y ago
      It dissuades people who aren’t comfortable with Makefiles and Vim from using C, so I’d agree it’s gatekeep-y.
      - kragen 3y ago
        i think that's the opposite of the intent they're saying that you don't need to be comfortable with ides and fancy debuggers and cmake and language servers and game development engines and ci pipelines and all kinds of complicated stuff to write c successfully a bare-bones text editor and the most minimal build system are plenty and if they aren't plenty, they're not saying that's a problem with you, but with c i don't agree (ctags, valgrind, git, and gdb go a long way towards making c usable, and evidently c is the best language for a lot of things even ctags and gdb struggle with, like linux kernel drivers, and cmake evidently helps a lot if you care about ms-windows) but that's what they said, and you totally misunderstood them because you somehow got the idea that vim and make are some kind of super advanced tools rather than relics from the 01980s they're maybe a bit unprepossessing at first glance but mostly what they are is simple and primitive think of using a hammer rather than a cam-driven turret lathe you can go lower tech than make too now that cpus and c compilers are so fast while sleep 1; do # ci pipeline gcc -Wall -funny -mtune=i69 *.c -lm -liberty -letmypeoplego -o proggie && # build system ./proggie --run-tests # test runner done c compiles fast enough that this scales to several thousand lines of code, c++ very much does not of course you need a testing framework if (!strcmp(argv[1], "--run-tests")) return run_tests(); ... three seconds latair ... int run_tests() { return test_ui() || test_network() || test_parsing(); } int test_parsing() { assert(trees_equal(parse("3+4"), parse("3 + 4"))); assert(!trees_equal(parse("3+4"), parse("3 + 5"))); ... } now i'm not saying you shouldn't write a test runner in unity and distribute your ci pipeline with zmq and mqtt and whatever the fuck. better ux is worth my weight in gold, and i have programmer gut. also zmq is metal as fuck what i am saying is that the difference between no test runner and an infinite loop in bash is much bigger than the difference between the bash loop and circleci or gitlab pipelines. so don't be intimidated by articles like this which make it sound like you need a team of phds to set up a test runner. writing tests and running them is what helps, not so much stylishness except for version control. a build script in shell is a serviceable alternative to make, but cp -a proggie/src snapshot.$(date +%Y-%m-%d) is not a serviceable alternative to git also if 3d test runners with inotify and particle systems with custom shaders mean that people write more tests and see the tests fail sooner after they break shit, that could make a real difference
0xbadcafebee 3y ago
since the container is executed in a VM, the I/O performance is significantly worse compared to a container that is run natively. For compiled languages or for any process that creates a lot of files, this impact can be significant since the overhead can be up to 100x of what you’re experiencing natively Uhhhhhhh. I don't know what VM you're using... but if the I/O in your VM is 100x slower than the host, you can fix that. It should not take a minute and a half to write a single file.
- maccard 3y ago
  I'm guessing OP is on Docker for Mac. This isn't so much a VM is slow, it's that file IO on docker for mac on mounted volumes is dog slow. (It's not exactly ripping fast on windows either). If you don't mount the intermediate directory, it'll be way faster. Alternatively, use OrbStack (I feel like I'm shilling this a lot recently, I'm just a happy user), and the problem goes away.
  - rtpg 3y ago
    And for everyone who has these problems and aren't, like, people who need access to Photoshop, it's "native performance" on Linux cuz there's no VM layer. It could be that the VSCode remote container stuff also gets around this problem somewhat by working "in container", effectively opting out of the Mac->Docker FS stack issues (especially with file watching....). The fact that we have an enumerable number of tools that write files and somehow ended up with a bunch of stuff built on file watching instead of signaling to a build daemon on file save/checkout is... It feels cleaner but in practice is a mess of downstream problems.
- p_l 3y ago
  Sounds like a case of "Running Docker Desktop on a Mac and editing file on filesystem mounted from host".
  - znpy 3y ago
    More like: writing to an overlay filesystem mounted on top of several more overlay filesystem running in a linux virtual machine started by docker desktop on a mac.
anon7331 3y ago
My idea of a C development environment has always been Vim, Tmux and a decent compiler.
maccard 3y ago
I'm a big containers fan, they work really well (assuming you're not developing with MSVC). They give you a repeatable build environment, which is a boon for something like C where you're implicitly depending on system include paths for versioning. I said this elsewhere, but you'll get a pretty decent perf boost if you set your build intermediate directory outside your mounted volume. Instead of rm -rf /var/lib/apt/lists/*, running `apt-get clean` as part of that layer will help more. Wrapping docker commands with makefiles is sad times. Use https://magefile.org/ https://magefile.org/ or a task runner instead. Try to avoid making it a scripting language dependency. Installing ruby to install a build system when you're using cmake in the container is a bit bonkers, and the cause of the majority of the "bloat" here. I'd replace it with calls to cmake and unity directly. (And honestly, if you're going as far as using cmake, I'd ditch C altogether and usea subset of C++ with gtest) But honestly, that's about all I can complain about. This is a neat, modern workflow.
- GuB-42 3y ago
  > I'm a big containers fan, they work really well (assuming you're not developing with MSVC). They give you a repeatable build environment, which is a boon for something like C where you're implicitly depending on system include paths for versioning. For development, I actually don't like "repeatable build environments". I like using a different, continuously updated systems, I consider having a different environment for CI/CD and for development to be a good thing. It is one of the best way to test for compatibility problems, a kind of dogfooding. Plus, it is nice working on a system you are comfortable with, and without the performance penalties of virtualization/containerization. For releasing and testing however, containers are great.
- forrestthewoods 3y ago
  > where you're implicitly depending on system include paths for versioning The correct thing to do, imho, is check-in toolchains to version control.
  - maccard 3y ago
    Yeah that works really well. I used to use the predecessor of "Turnkey" [0] for unreal engine, and it worked absolutely great for that problem. [0] https://docs.unrealengine.com/5.0/en-US/setting-up-turnkey-for-your-organization-in-unreal-engine/ https://docs.unrealengine.com/5.0/en-US/setting-up-turnkey-f...
38 3y ago
> A Modern C Development Environment OK fine > 09 Aug 2023 huh? the correct answer to this question should be "get a time machine and go back to 2003 or something. why people insist on carrying on with C in the face of its glaring issues is beyond me. I am not advocating for any specific language, because several other languages are around that might be a better fit. Rust, Zig, D, Nim, Go. just please let C die already.
- znpy 3y ago
  > why people insist on carrying on with C in the face of its glaring issues is beyond me. Most people and companies cant delay new features and bug fixes for years with the excuse of “we’re rewriting the thing in $currently_trending_language”
  - 38 3y ago
    > $currently_trending_language by your definition, is that any language less than 50 years old?
    - seabass-labrax 3y ago
      That would be more like 30 years since C was truly trendy, and maybe 20 in some areas like embedded software engineering and games development. C was the top of the pile for decades, and I think when you compare it strictly to other languages that were available during that time it becomes clear why (not that is necessarily better than those other languages, but why it was so terrifically popular).
      - pjmlp 3y ago
        Ah, that is why we now have everyone cheering for Zig, which is basically Modula-2 (1978) with C like syntax. Apparently since the Morris worm (1988), it took a while to undestand what kind of features C was capable of.
- The_Colonel 3y ago
  From the languages you listed, only Zig is somewhat suitable as a C replacement, and it hasn't even reached v1.0.
pengaru 3y ago
This post has very little to do with C development and far more to do with using Docker to have quasi-reproducible development environments. Quasi because when your provisioning automation is doing things like `apt update` and grabbing the latest and greatest toolchains from third party repos, you're still producing an entirely unpredictable result.
- SV_BubbleTime 3y ago
  I was a little confused why the article didn’t recommend pulling specific versions by hash.
benreesman 3y ago
The cost in learning curve and weird edge cases on NixOS / flakes is debatable for any language ecosystem with some kind of Python-style virtual env or Rust-style (correctly) build the world. In C/C++ land? Nix is the virtual env. It’s the only sane choice for that as a user land stack.
guessbest 3y ago
As much as I hate to say it, XCode is a really good C development environment that also works with C++. I've never had to mess with a makefile.
- wruza 3y ago
  For all IDEs I’ve used, this meant a dead simple makefile, nothing to mess with. When I had to, I had to mess with these fancy envs even more, or they just couldn’t do it. But if you meant that learning make is harder than using an IDE, then I agree. But why specifically XCode then? Lots of IDEs know C/C++ off the shelf.
patrick451 3y ago
I've had jobs where we used a containerized dev evironment like this. I've had others where we just installed all the dependencies to our dev machines. The container environment is hands down the worse experience of the two. Similar to this tutorial, if you don't want to use the blessed editor, you end up maintaining your own docker container. Similarly if you want to use tools not installed into the official container (say, ripgrep). I'll take updating a dependency on my dev machine every now and then (which could be largely eliminated if we had used something like conan) over maintaining my own docker image any day. You can also largely eliminate relying on system headers through --sysroot, which cmake supports. Another issue we had, which this tutorial doesn't appear to address, is that these containers run as root, so files created in them on a mounted folder easily end up as owned by root. Which can create all sorts of mayhem. The only reliable solution I have seen is to dynamically change the container users uid and gid on login, but this often doesn't seem to get implemented.
jedisct1 3y ago
Forget cmake in 2023. Using Zig is way easier, faster and more flexible. I'm not talking about Zig as a language, but as a toolchain to compile C/C++ code.
munificent 3y ago
For my past few C/C++ projects, my very enjoyable development environment has been: * XCode * Makefile That's really it. If I found myself needing to set up Docker... I'd just go outside and garden instead or something.
- jandrese 3y ago
  Yeah, as soon as the article started talking about setting up a Docker instance to compile some C code I was out. It's like they went out of their way to make a C compile take as long as a modern language.
antiviral 3y ago
The C language is like 'an elegant weapon for a more civilized age.' This article reminds me of an idea I once had: to write a memory manager/garbage collector for C. The challenge is to know the scope of a dynamically managed chunk of memory. Using that, the memory can be automatically garbage-collected, but this is difficult since C wasn't designed for this in mind. I'm curious if anyone has any other experiences they can share.
- bobowzki 3y ago
  https://www.hboehm.info/gc/ https://www.hboehm.info/gc/
  - tmtvl 3y ago
    That was my first reaction as well, I haven't really used it, but it's an interesting tool.
  - convolvatron 3y ago
    I did this once - a compacting collector for C. it was a really trivial mark/sweep - and as I recall you had to write functions for each type to perform the object graph traversal. for artificial memory-intensive workloads it was around 8x the performance of boehm.
    - antiviral 3y ago
      Is this anything you'd be willing to share publicly? How did you determine the scope of a chunk of memory? I believe you need this to run any of the GC algorithms. I checked the hboehm documentation (1) and in the section on "Locating roots" it says "you don't want to know": -Runtime stack(s): you don't really want to know.Need consistent caller-save reg. snapshot -Static data segments: you don't want to know that either. -Very platform dependent But you only have to do it once per platform. (1) https://www.hboehm.info/gc/04tutorial.pdf https://www.hboehm.info/gc/04tutorial.pdf
      - convolvatron 3y ago
andrewmcwatters 3y ago
You can do all of this, but aside from some oddball project setups, virtually no one else in the C or C++ ecosystem does this. Everyone uses CMake (C++), or even just Makefiles (C). You are working against yourself, because eventually you will need to learn CMake and Make when you have to interop with other projects. In day-to-day use, I find that there is very little that is actually modern about C or C++, and that's OK. Just focus on getting things done, and build up a working knowledge of all of the practical stupid things you have to do when working with C and C++ projects. Like, it's bewildering that there are no cross-platform CMake recipes for building an app. Totally wild. But everyone slogs through this stupid nonsense while other platforms hand it to you on a platter. Just deal with it. There are other hills to die on that are wildly more important. Help others that struggle with arcane CMake b.s.
hsn915 3y ago
I was hoping one can setup a "modern" C development environment without resorting to Docker. Using Docker for setup a C development environment indicates that there are too many moving parts and the development environment is essentially very complex and that there's nothing that one do about it. I wish more people would write such guides with the aim of reducing the development environment to its essentials that can be installed system-wide without being disruptive and thus not needing "Docker".
- snvzz 3y ago
  Using docker merely ensures the environment can be quickly reproduced anywhere, anytime it is needed. It is entirely optional, yet extremely useful.
- piaste 3y ago
  Oh, you can surely install a minimal development environment system-wide. Once. Containers just enable you to do it more than once. And they leave you a plaintext napkin with the list of stuff you installed.
- kkoste 3y ago
  I have a C project template for VSCode that I just copy whenever I start a new C-project. Inspiration for it was mostly because I don't want to rewrite the same CMake code constantly. But I think there are a lot of these kind of projects floating around out there on github. I use mingsys though . But theoretically it should be no trouble to change the compiler.
- P_I_Staker 3y ago
  That wouldn't be very "modern"
- legobmw99 3y ago
  Obviously it is goal dependent, but if you eventually want your code to run on a variety of machines and systems, I find docker to actually be a barrier. Having a different environment in CI than local can be annoying, but it’s also the first time you are forced to confront the “but it runs on my laptop!” problem
deleted 3y ago
[deleted]
- deleted 3y ago
  [deleted]
cushychicken 3y ago
To everyone dogpiling on this guy: a better title would be "A Modern Embedded C Development Environment". There's a bunch of problems that Docker solves for embedded toolchains that other C developers don't need to care about.
- sheepshear 3y ago
  Can you elaborate? I've appreciated it in a few specific situations but I haven't found where it's categorically better than the alternatives.
  - cushychicken 3y ago
    Docker is a handy way to keep a hold on toolchains that might require a bit of arcane configuration, or the chaining together of a bunch of different tools. The author's example isn't really the best at illustrating this as he's just apt-get'ing things like gcc. There are plenty of cases where you'll need some specific version of gcc or some other weird tool like openocd or gdb that's hard to hunt down, or is required due to some weird development ephemera you found. Docker makes it a bit easier to compile these requirements and hang on to them painlessly - even across a few years' time lag.
    - sheepshear 3y ago
      It sounds like docker is maybe what got you started saving tools, but if not, how does it compare to your old method (virtual machines or whatever)?
      - cushychicken 3y ago
        I've used VMs, and they work - when you have the same computer. When you upgrade equipment and need to repro an environment, Docker proves to be the lighter lift.
demondemidi 3y ago
This should be titled "A Modern -OPEN SOURCE- C Development Environment". If you work in the embedded space for a large OEM, ODM, or integration house, you won't see any of this ... you will see all commercial environments with big price tags for seats e.g. compilers will be ARMC, Green Hills, IAR; for DAST you'll see tools from Synopsys or Cadence (same for virtual prototyping); lots of ISO compliance tools from hard-to-remember small companies that do that for a living and charge a cool mil to setup and audit ... for CI/CD you will likely see GitLab if not home grown suites. Gnu tools are some of the worst. Containers? 30+ years at this with 10 major contracts with big companies (and dozens of smaller ones) and I've only seen one company use containers and that was for virtual prototyping. C environments move at 1/100th the speed of webdev because product cycles happen in 6-12 months: literally no time to bring up a new system that breaks everything (and for no real benefit).
- DoingIsLearning 3y ago
  > If you work in the embedded space for a large OEM, ODM, or integration house > Containers? 30+ years at this with 10 major contracts with big companies (and dozens of smaller ones) and I've only seen one company use containers and that was for virtual prototyping. There are _a_lot_ of small and medium size businesses working with embedded devices with limited on-site resources, and those will usually use external contractors. In that case containers are very useful to share an Automated Test environment. The alternative is a long back and forth or spending time on-site supporting teams with wildly varying skill levels. Also as someone else mentioned when an old client asks for a new feature, the ability to take a snapshot in time is a huge time saver, rather than trying to replicate that build environment from scratch.
  - demondemidi 3y ago
    I'm highly skeptical of the benefits of containers in the embedded space. The inertia required to set them up and maintain them, and train customers to use them is massive. I'm sure some people benefit somewhere, but in my experience people want a zip file of your code base, platform support package version, and compiler version, ... that's 99% of it. Working with ARC/MSP430/ATMEL/PIC/Cortex-M devices for decades I have rarely seen a codebase over 10 megabytes of customer C code.
manofmanysmiles 3y ago
Having spent a decade building embedded C, its refreshing to see that I'm not the only one who sees the value in doing things well. Every single one of the steps here, though they may seem excessive provide immense value, not at first, but as the project grows, matures, and needs to exist for decades. I am rather surprised at all the negativity here. I assume that it's either few of the people commenting have worked on embedded systems, or the few that do do not have an appreciation for maintaining a large project for the long term. Attitudes like I'm seeing expressed here are reinforcing my desire to get away from embedded, or at last work with people that don't wish to stay stuck in the stone age. I'm not intending to argue here, just surprised and a bit sad at the reactions, and happy that some people, at least at memfault share my values.
- randmeerkat 3y ago
  > Attitudes like I'm seeing expressed here are reinforcing my desire to get away from embedded, or at last work with people that don't wish to stay stuck in the stone age. I hate to break it to you, but there’s the same problems on the SWE side too. The problem is never the stack, it’s the culture. If you’re tired of embedded, that’s fine, but remember to ask culture questions for your next position.
  - manofmanysmiles 3y ago
    That’s disheartening, but not surprising. > remember to ask culture questions for your next position. I will definitely take that under advisement. Any places you recommend I look into?
    - randmeerkat 3y ago
      > That’s disheartening, but not surprising. Don’t be discouraged, it’s just life. > I will definitely take that under advisement. Any places you recommend I look into? Ask yourself what you want? What do you want in a leader? What do you want in a company? Be picky, be patient, if you can, maybe start something yourself. I wish I could tell you what would be the right fit for you, but I can’t. All I can say is don’t lose hope, but at the same time don’t expect too much either. We’re all just trying to figure out this thing called life, whether we’re embedded engineers, SWEs, or even sales for that matter.
nitwit005 3y ago
> Dockerfiles are not stable. A Dockerfile that built just fine yesterday might fail to build today. There are simply too many external dependencies. > Docker is not platform-independent. Especially if you’re running a container on other CPU architectures, e.g., Apple ARM, you’ll notice that some things don’t run. We’ll see this later. And it keeps going on about how Docker doesn't really solve the problem.
zer8k 3y ago
Not bad except for visual studio devcontainers. Absolutely gross solution to a problem I've never faced in over a decade of professional development. I can see docker in some cases (rarely) for C programming. But devcontainers? That's like reaching around your head to touch your nose. I know plenty of people that use them and every time I watch them to try to glean some insight I am left more confused than I started. It seems so stilted. I always get "its a better experience!" but never any explanation why. Like everyone who uses them watched the same Microsoft sponsored youtube video selling them. None of this solves C's only REAL problem (in my opinion) which is the lack of dependency management. Most everything else can be done with a makefile and a half decent editor. No need to step up into vscode if you don't want to. Clang LSPs are basically everywhere and just fine.
- torstenvl 3y ago
  My solution: git submodules + every project stores its main sources in src/ + Makefile that recursively searches for "src/*.c" files and compiles them to a big ol object collection. It's obviously not infinitely scaleable because you could end up with name conflicts for object files, or some modules might require custom build settings. But it works well enough to nest my own projects 3-4 layers deep without issue.
  - duped 3y ago
    git submodules have ruined my life on multiple teams enough to never want them. They're good enough for a dev team of 2-3 but don't scale very well. git subtree can be a bit better. But ultimately you probably want a working package manager.
    - eonwe 3y ago
      I've heard this often. Why don't they scale? I used them for some years for a team of ten or so people who all first had to learn to understand how they worked so might that be the problem?
      - 3y ago
xvilka 3y ago
I wouldn't use Debian or Ubuntu as Docker base for this since they always ship heavily outdated software. Alpine as a base offers slimmer image but also updated tools and libraries, including GCC and Clang. Article speaks about GCC 10 which is prehistoric by today standards.
- piaste 3y ago
  Can the dev environment and toolchain be affected by Alpine being musl-based?
  - xvilka 3y ago
    It's possible, but you can install glibc optionally[1]. [1] https://wiki.alpinelinux.org/wiki/Running_glibc_programs https://wiki.alpinelinux.org/wiki/Running_glibc_programs
emmanueloga_ 3y ago
The setup described is incredibly involved ... I'm doing some ESP32 experiments and plan to investigate PlatformIO which seems to provide solutions to most of the problems described in the OP. PIO supports a bunch of platforms and also provides a way to create your own if necessary [1]. 1: https://docs.platformio.org/en/latest/platforms/creating_platform.html https://docs.platformio.org/en/latest/platforms/creating_pla...
buserror 3y ago
[dead]
travisgriggs 3y ago
I switched from fighting VSCode and plug-in hell to Nova with Seadragon a couple of months ago. At the end of the trial window, I had no problem ponying up money for Nova. I don’t even know where to start on the myriad little ways I like Nova better.
pjmlp 3y ago
Great article, specially by going into unit testing and use of static analysis tooling.
flohofwoe 3y ago
I hope beginners don't get the impression that all this is needed for developing in C. If you want a free (as in beer) and 'good enough' multi-platform solution without tinkering, just use VSCode with 2 extensions: - https://marketplace.visualstudio.com/items?itemName=ms-vscode.cpptools https://marketplace.visualstudio.com/items?itemName=ms-vscod... - https://marketplace.visualstudio.com/items?itemName=ms-vscode.cmake-tools https://marketplace.visualstudio.com/items?itemName=ms-vscod... This gives you a cmake-based IDE-like setup that works across Linux, macOS and Windows (and also allows to build and debug UI applications with the native OS APIs).
brabel 3y ago
`apt install` is just installing a whole lot of utilities without specifying any version. This environment will only last a couple of years (and that's generous because the kind of stuff you're installing, like cmake, gcc, curl, maybe ruby(?) tend to be stable, but at some point one of them will break something you were using). It's the old dilema everyone faces: pin every dependency version to guarantee you have a stable environment that will work in 20 years as long as things can still be downloaded? OR use the latest of everything, making a hugely unstable environment you have to keep fixing every few months, but at least get the latest "security patches" and other improvements (as well as new bugs)?
- piaste 3y ago
  Yeah, not pinning versions in a container build is bad practice imo. Though, I haven't used Debian-based distros in a while, but does apt actually serve really old versions of its packages? I vaguely seem to remember that you could realistically only `apt install` the last few versions of a package.
  - brabel 3y ago
    You can install specific versions of libs with apt[1] but only if that happens to be compatible with your system deps... it's possible to run into trouble where one utility you install requires openssl 3 and another requires the latest version, and then you can't have both libs together easily. But normally, a distro is meant to keep a bunch of utilities with compatible versions for you. I just think that this way of doing things may not be appropriate for building software, and if you look at how Nix does it, for example, you can see that they break up with the traditional Linux distro system and let you have multiple environments with different libraries installed - and you can totally pin everything to make sure it will work forever (or until the sources/binaries can be fetched). [1] https://askubuntu.com/questions/92019/how-to-install-specific-ubuntu-deb-packages-with-exact-version https://askubuntu.com/questions/92019/how-to-install-specifi...
    - piaste 3y ago
      Yeah but I assume that you'd be pinning the base image, in addition to whatever you apt install. If I install, let's say Debian 6, can I use `apt install package=version ` to install the 2011 versions of most packages?
InvOfSmallC 3y ago
I have a side job of teacher at university, sometimes I have to teach C fundamentals. I was looking into giving my students a standard setup. This looks awesome. Have my thanks.
domenkozar 3y ago
That's a mouthful for 14 lines of native development that can generate a dev container using https://devenv.sh https://devenv.sh $ cat devenv.nix { pkgs, ... }: { languages.c.enable = true; packages = [ pkgs.ceedling pkgs.cmake ]; enterShell = '' cmake --version ''; pre-commit.hooks = { clang-format.enable = true; clang-tidy.enable = true; }; } $ devenv shell (Note that pkgs.ceedling has been recently added and will only hit the cache in 6-12h).
physicsguy 3y ago
I just use Spack these days for managing C/C++ dependencies. I don't really see the need for Docker when you're building a binary.
floor_ 3y ago
0% of this is necessary. "Modern" these days seems to just be another word for "bloated" or "bad".
crabbone 3y ago
I don't find none of the things author is using to be useful, or do I ever use them in my C development process. I don't have a need for Docker or any containers for that matter, unless the goal is to deploy in containers. I would never touch VSCode with a ten feet pole. Same goes for CMake -- unless forced to by external circumstances, I will never use it. Even if this environment was set up by someone else for me, I would've found it painfully difficult and uncomfortable to use... so, I don't know why would anyone else want this.

239 points by 5ADBEEF 3y ago

Also see: Make Zig Your C/C++ Build System https://zig.news/kristoff/make-zig-your-c-c-build-system-28g5 https://zig.news/kristoff/make-zig-your-c-c-build-system-28g... Edit: this is a better demo (thanks jmull) https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...

david2ndaccount 3y ago
Doesn’t seem to offer much over just using clang.
- jmull 3y ago
  Here's some more info why you might use this instead of plain clang. https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...
- klardotsh 3y ago
  Other than the complete lack of writing CMake, Makefiles, autoconf, or any number of other end-user-configuration complicated systems as such, and other than the trivial statically-linked cross-compilation support, sure, I guess it's "just" a wrapper around clang, if you squint.
  - david2ndaccount 3y ago
    If you aren’t supporting more than one compiler, almost all of those tools vanish. You can just use clang.
    - klardotsh 3y ago
      If you aren't supporting more than one compiler, aren't needing to compile anything in parallel, aren't needing to find and link shared libraries on the system, aren't needing to deal with any number of real complexities that happen when building C software, then sure, build.sh calling clang a few times manually is absolutely reasonable. (And again: cross-compilation is a real concern: shipping for amd64 only is not enough in 2023). And to be clear - there are plenty of small-scale projects that fit this description! But to simply hand-wave away `zig build` or other modernized build systems and say "just use clang directly" seems a bit dishonest or incomplete to me.
      - david2ndaccount 3y ago
        Note that I am not advocating for just having a few shell scripts that invoke clang. The context is someone saying to use `zig build`, and linking a blog post where all they do is compile redis from scratch, including all dependencies from source except for libc. In that context, `zig build` is just a wrapper around clang. Nowhere in their comment or linked blog post is the issue of these real complexities you allude to addressed at all. Now I personally would rather not use a pre 1.0 release of an entirely different programming language to compile my C projects instead of a cross-platform C compiler, but people can do whatever they want.
    - reverius42 3y ago
      Or more than one operating system, or more than one stdlib, etc., etc.
    - convolvatron 3y ago
      to be fair - my goto move on a smallish project when autoconf barfs is 'cc *.c -o foo'. it works pretty damn often, sometimes you need to throw in some -I action
  - rewmie 3y ago
    > or any number of other end-user-configuration complicated systems as such If you think that cmake is complicated, when in reality all it does is set targets using a declarative stye, then programming might not be for you.
    - klardotsh 3y ago
      Personal attacks are pretty unnecessary here, thanks. This kind of comment is what gives (some) C developers the reputation they have in some circles, I guess.
    - duped 3y ago
      > when in reality all it does is set targets using a declarative stye That's like the hello world of cmake builds Bigger cmake builds are doing dependency resolution, configuration tests, and configuration for development or release builds/installs. Go poke at the cmake logs and result artifacts in Debug/Release build types and see if it's "just declaring targets."
      - rewmie 3y ago
        > Bigger cmake builds are doing dependency resolution, find_package(foo) #... target_link_libraries(myapp foo::Static) > configuration tests, I don't know what you mean by configuration tests. I don't think I ever added any test resembling that description other than sanity checks in cmake find modules and sanity checks on projects just for convenience. > and configuration for development or release builds Those are not handled by cmake other than setting a flag that's used in the code. > /installs. You don't need to do anything other than setting the install target. https://cmake.org/cmake/help/latest/command/install.html https://cmake.org/cmake/help/latest/command/install.html I think you're either wildly exaggerating or you've been creating your own problems.
        duped 3y ago
        Ok. How does find_package work? Hint: you need to understand how cmake module paths are discovered and their precedence, and you'll probably see a cmake folder in a build with the actual logic behind it as a .cmake file for each dependency. Depending on what package manager you're using you may not need this, or if you support many you'll need to own it. > I don't know what you mean by configuration tests. When you run cmake -S <my project> -B build folder you'll see a bunch of output. What this output corresponds to may include a number of tests that either succeed or fail to indicate whether the project will build. For example, the aforementioned find_package logic, finding the compiler tool chain (especially if cross compiling), testing for random shit like endianness, etc. > Those are not handled by cmake other than setting a flag that's used in the code. if(STREQ ${CMAKE_BUILD_TYPE} Release) .... endif() Is ridiculously common with the "..." filled in by various things like setting optimization flags, paths within the build directory, etc > You don't need to do anything other than setting the install target. No but you should probably understand what RPATH is and why it's set in release builds but not installed artifacts or why doing something that seems obvious like checking the checksum of your built object is the same as the installed one might fail. The point is that cmake does a lot of work and it's not just declaring targets. Builds are hard.
  - schemescape 3y ago
    Out of curiosity, what DO you write instead of Makefiles in this case? I’m genuinely curious if it’s actually easier, but I’m assuming you’re just using a different tool, maybe without as much historical baggage (and incompatible implementations)…
gkfasdfasdf 3y ago
I thought zig was removing 'zig cc' support?
- ttrei 3y ago
  Not really: https://github.com/ziglang/zig/issues/16270#issuecomment-1616115039 https://github.com/ziglang/zig/issues/16270#issuecomment-161...
  - gkfasdfasdf 3y ago
    That's good to know, thanks

ryan-c 3y ago

At the risk of being featured in a future episode of "Hacker News reacts to (Dropbox|iPhone)"... ...a Makefile and vim (or emacs, or even nano, I'm not going to judge your kink) are fine. If they are not fine, then C is probably not the right language for the project.

hot_gril 3y ago
My last project in C had a CMake file that generated a Makefile, idk if you consider that too much.
Aurornis 3y ago
> If they are not fine, then C is probably not the right language for the project. This is called gatekeeping and it’s not helpful. It’s fine to write C in vim/emacs/nano if you want. It’s fine to write C in Visual Studio Code if you want. It’s fine to write C in CLion if you want. There is nothing wrong with any approach and no need to gatekeeper an entire programming language based on editor preference.
- the-printer 3y ago
  Is it really gatekeeping? Does this opinion (that was valid and useful to me) carry any preventive force that the term suggests?
  - bryancoxwell 3y ago
    It dissuades people who aren’t comfortable with Makefiles and Vim from using C, so I’d agree it’s gatekeep-y.
    - kragen 3y ago
      i think that's the opposite of the intent they're saying that you don't need to be comfortable with ides and fancy debuggers and cmake and language servers and game development engines and ci pipelines and all kinds of complicated stuff to write c successfully a bare-bones text editor and the most minimal build system are plenty and if they aren't plenty, they're not saying that's a problem with you, but with c i don't agree (ctags, valgrind, git, and gdb go a long way towards making c usable, and evidently c is the best language for a lot of things even ctags and gdb struggle with, like linux kernel drivers, and cmake evidently helps a lot if you care about ms-windows) but that's what they said, and you totally misunderstood them because you somehow got the idea that vim and make are some kind of super advanced tools rather than relics from the 01980s they're maybe a bit unprepossessing at first glance but mostly what they are is simple and primitive think of using a hammer rather than a cam-driven turret lathe you can go lower tech than make too now that cpus and c compilers are so fast while sleep 1; do # ci pipeline gcc -Wall -funny -mtune=i69 *.c -lm -liberty -letmypeoplego -o proggie && # build system ./proggie --run-tests # test runner done c compiles fast enough that this scales to several thousand lines of code, c++ very much does not of course you need a testing framework if (!strcmp(argv[1], "--run-tests")) return run_tests(); ... three seconds latair ... int run_tests() { return test_ui() || test_network() || test_parsing(); } int test_parsing() { assert(trees_equal(parse("3+4"), parse("3 + 4"))); assert(!trees_equal(parse("3+4"), parse("3 + 5"))); ... } now i'm not saying you shouldn't write a test runner in unity and distribute your ci pipeline with zmq and mqtt and whatever the fuck. better ux is worth my weight in gold, and i have programmer gut. also zmq is metal as fuck what i am saying is that the difference between no test runner and an infinite loop in bash is much bigger than the difference between the bash loop and circleci or gitlab pipelines. so don't be intimidated by articles like this which make it sound like you need a team of phds to set up a test runner. writing tests and running them is what helps, not so much stylishness except for version control. a build script in shell is a serviceable alternative to make, but cp -a proggie/src snapshot.$(date +%Y-%m-%d) is not a serviceable alternative to git also if 3d test runners with inotify and particle systems with custom shaders mean that people write more tests and see the tests fail sooner after they break shit, that could make a real difference

0xbadcafebee 3y ago

since the container is executed in a VM, the I/O performance is significantly worse compared to a container that is run natively. For compiled languages or for any process that creates a lot of files, this impact can be significant since the overhead can be up to 100x of what you’re experiencing natively Uhhhhhhh. I don't know what VM you're using... but if the I/O in your VM is 100x slower than the host, you can fix that. It should not take a minute and a half to write a single file.

maccard 3y ago
I'm guessing OP is on Docker for Mac. This isn't so much a VM is slow, it's that file IO on docker for mac on mounted volumes is dog slow. (It's not exactly ripping fast on windows either). If you don't mount the intermediate directory, it'll be way faster. Alternatively, use OrbStack (I feel like I'm shilling this a lot recently, I'm just a happy user), and the problem goes away.
- rtpg 3y ago
  And for everyone who has these problems and aren't, like, people who need access to Photoshop, it's "native performance" on Linux cuz there's no VM layer. It could be that the VSCode remote container stuff also gets around this problem somewhat by working "in container", effectively opting out of the Mac->Docker FS stack issues (especially with file watching....). The fact that we have an enumerable number of tools that write files and somehow ended up with a bunch of stuff built on file watching instead of signaling to a build daemon on file save/checkout is... It feels cleaner but in practice is a mess of downstream problems.
p_l 3y ago
Sounds like a case of "Running Docker Desktop on a Mac and editing file on filesystem mounted from host".
- znpy 3y ago
  More like: writing to an overlay filesystem mounted on top of several more overlay filesystem running in a linux virtual machine started by docker desktop on a mac.

anon7331 3y ago

My idea of a C development environment has always been Vim, Tmux and a decent compiler.

maccard 3y ago

I'm a big containers fan, they work really well (assuming you're not developing with MSVC). They give you a repeatable build environment, which is a boon for something like C where you're implicitly depending on system include paths for versioning. I said this elsewhere, but you'll get a pretty decent perf boost if you set your build intermediate directory outside your mounted volume. Instead of rm -rf /var/lib/apt/lists/*, running `apt-get clean` as part of that layer will help more. Wrapping docker commands with makefiles is sad times. Use https://magefile.org/ https://magefile.org/ or a task runner instead. Try to avoid making it a scripting language dependency. Installing ruby to install a build system when you're using cmake in the container is a bit bonkers, and the cause of the majority of the "bloat" here. I'd replace it with calls to cmake and unity directly. (And honestly, if you're going as far as using cmake, I'd ditch C altogether and usea subset of C++ with gtest) But honestly, that's about all I can complain about. This is a neat, modern workflow.

GuB-42 3y ago
> I'm a big containers fan, they work really well (assuming you're not developing with MSVC). They give you a repeatable build environment, which is a boon for something like C where you're implicitly depending on system include paths for versioning. For development, I actually don't like "repeatable build environments". I like using a different, continuously updated systems, I consider having a different environment for CI/CD and for development to be a good thing. It is one of the best way to test for compatibility problems, a kind of dogfooding. Plus, it is nice working on a system you are comfortable with, and without the performance penalties of virtualization/containerization. For releasing and testing however, containers are great.
forrestthewoods 3y ago
> where you're implicitly depending on system include paths for versioning The correct thing to do, imho, is check-in toolchains to version control.
- maccard 3y ago
  Yeah that works really well. I used to use the predecessor of "Turnkey" [0] for unreal engine, and it worked absolutely great for that problem. [0] https://docs.unrealengine.com/5.0/en-US/setting-up-turnkey-for-your-organization-in-unreal-engine/ https://docs.unrealengine.com/5.0/en-US/setting-up-turnkey-f...

38 3y ago

> A Modern C Development Environment OK fine > 09 Aug 2023 huh? the correct answer to this question should be "get a time machine and go back to 2003 or something. why people insist on carrying on with C in the face of its glaring issues is beyond me. I am not advocating for any specific language, because several other languages are around that might be a better fit. Rust, Zig, D, Nim, Go. just please let C die already.

znpy 3y ago
> why people insist on carrying on with C in the face of its glaring issues is beyond me. Most people and companies cant delay new features and bug fixes for years with the excuse of “we’re rewriting the thing in $currently_trending_language”
- 38 3y ago
  > $currently_trending_language by your definition, is that any language less than 50 years old?
  - seabass-labrax 3y ago
    That would be more like 30 years since C was truly trendy, and maybe 20 in some areas like embedded software engineering and games development. C was the top of the pile for decades, and I think when you compare it strictly to other languages that were available during that time it becomes clear why (not that is necessarily better than those other languages, but why it was so terrifically popular).
    - pjmlp 3y ago
      Ah, that is why we now have everyone cheering for Zig, which is basically Modula-2 (1978) with C like syntax. Apparently since the Morris worm (1988), it took a while to undestand what kind of features C was capable of.
The_Colonel 3y ago
From the languages you listed, only Zig is somewhat suitable as a C replacement, and it hasn't even reached v1.0.

pengaru 3y ago

This post has very little to do with C development and far more to do with using Docker to have quasi-reproducible development environments. Quasi because when your provisioning automation is doing things like `apt update` and grabbing the latest and greatest toolchains from third party repos, you're still producing an entirely unpredictable result.

SV_BubbleTime 3y ago
I was a little confused why the article didn’t recommend pulling specific versions by hash.

benreesman 3y ago

The cost in learning curve and weird edge cases on NixOS / flakes is debatable for any language ecosystem with some kind of Python-style virtual env or Rust-style (correctly) build the world. In C/C++ land? Nix is the virtual env. It’s the only sane choice for that as a user land stack.

guessbest 3y ago

As much as I hate to say it, XCode is a really good C development environment that also works with C++. I've never had to mess with a makefile.

wruza 3y ago
For all IDEs I’ve used, this meant a dead simple makefile, nothing to mess with. When I had to, I had to mess with these fancy envs even more, or they just couldn’t do it. But if you meant that learning make is harder than using an IDE, then I agree. But why specifically XCode then? Lots of IDEs know C/C++ off the shelf.

patrick451 3y ago

I've had jobs where we used a containerized dev evironment like this. I've had others where we just installed all the dependencies to our dev machines. The container environment is hands down the worse experience of the two. Similar to this tutorial, if you don't want to use the blessed editor, you end up maintaining your own docker container. Similarly if you want to use tools not installed into the official container (say, ripgrep). I'll take updating a dependency on my dev machine every now and then (which could be largely eliminated if we had used something like conan) over maintaining my own docker image any day. You can also largely eliminate relying on system headers through --sysroot, which cmake supports. Another issue we had, which this tutorial doesn't appear to address, is that these containers run as root, so files created in them on a mounted folder easily end up as owned by root. Which can create all sorts of mayhem. The only reliable solution I have seen is to dynamically change the container users uid and gid on login, but this often doesn't seem to get implemented.

jedisct1 3y ago

Forget cmake in 2023. Using Zig is way easier, faster and more flexible. I'm not talking about Zig as a language, but as a toolchain to compile C/C++ code.

munificent 3y ago

For my past few C/C++ projects, my very enjoyable development environment has been: * XCode * Makefile That's really it. If I found myself needing to set up Docker... I'd just go outside and garden instead or something.

jandrese 3y ago
Yeah, as soon as the article started talking about setting up a Docker instance to compile some C code I was out. It's like they went out of their way to make a C compile take as long as a modern language.

antiviral 3y ago

The C language is like 'an elegant weapon for a more civilized age.' This article reminds me of an idea I once had: to write a memory manager/garbage collector for C. The challenge is to know the scope of a dynamically managed chunk of memory. Using that, the memory can be automatically garbage-collected, but this is difficult since C wasn't designed for this in mind. I'm curious if anyone has any other experiences they can share.

bobowzki 3y ago
https://www.hboehm.info/gc/ https://www.hboehm.info/gc/
- tmtvl 3y ago
  That was my first reaction as well, I haven't really used it, but it's an interesting tool.
- convolvatron 3y ago
  I did this once - a compacting collector for C. it was a really trivial mark/sweep - and as I recall you had to write functions for each type to perform the object graph traversal. for artificial memory-intensive workloads it was around 8x the performance of boehm.
  - antiviral 3y ago
    Is this anything you'd be willing to share publicly? How did you determine the scope of a chunk of memory? I believe you need this to run any of the GC algorithms. I checked the hboehm documentation (1) and in the section on "Locating roots" it says "you don't want to know": -Runtime stack(s): you don't really want to know.Need consistent caller-save reg. snapshot -Static data segments: you don't want to know that either. -Very platform dependent But you only have to do it once per platform. (1) https://www.hboehm.info/gc/04tutorial.pdf https://www.hboehm.info/gc/04tutorial.pdf
    - convolvatron 3y ago

andrewmcwatters 3y ago

You can do all of this, but aside from some oddball project setups, virtually no one else in the C or C++ ecosystem does this. Everyone uses CMake (C++), or even just Makefiles (C). You are working against yourself, because eventually you will need to learn CMake and Make when you have to interop with other projects. In day-to-day use, I find that there is very little that is actually modern about C or C++, and that's OK. Just focus on getting things done, and build up a working knowledge of all of the practical stupid things you have to do when working with C and C++ projects. Like, it's bewildering that there are no cross-platform CMake recipes for building an app. Totally wild. But everyone slogs through this stupid nonsense while other platforms hand it to you on a platter. Just deal with it. There are other hills to die on that are wildly more important. Help others that struggle with arcane CMake b.s.

hsn915 3y ago

I was hoping one can setup a "modern" C development environment without resorting to Docker. Using Docker for setup a C development environment indicates that there are too many moving parts and the development environment is essentially very complex and that there's nothing that one do about it. I wish more people would write such guides with the aim of reducing the development environment to its essentials that can be installed system-wide without being disruptive and thus not needing "Docker".

snvzz 3y ago
Using docker merely ensures the environment can be quickly reproduced anywhere, anytime it is needed. It is entirely optional, yet extremely useful.
piaste 3y ago
Oh, you can surely install a minimal development environment system-wide. Once. Containers just enable you to do it more than once. And they leave you a plaintext napkin with the list of stuff you installed.
kkoste 3y ago
I have a C project template for VSCode that I just copy whenever I start a new C-project. Inspiration for it was mostly because I don't want to rewrite the same CMake code constantly. But I think there are a lot of these kind of projects floating around out there on github. I use mingsys though . But theoretically it should be no trouble to change the compiler.
P_I_Staker 3y ago
That wouldn't be very "modern"
legobmw99 3y ago
Obviously it is goal dependent, but if you eventually want your code to run on a variety of machines and systems, I find docker to actually be a barrier. Having a different environment in CI than local can be annoying, but it’s also the first time you are forced to confront the “but it runs on my laptop!” problem

deleted 3y ago

[deleted]

deleted 3y ago
[deleted]

cushychicken 3y ago

To everyone dogpiling on this guy: a better title would be "A Modern Embedded C Development Environment". There's a bunch of problems that Docker solves for embedded toolchains that other C developers don't need to care about.

sheepshear 3y ago
Can you elaborate? I've appreciated it in a few specific situations but I haven't found where it's categorically better than the alternatives.
- cushychicken 3y ago
  Docker is a handy way to keep a hold on toolchains that might require a bit of arcane configuration, or the chaining together of a bunch of different tools. The author's example isn't really the best at illustrating this as he's just apt-get'ing things like gcc. There are plenty of cases where you'll need some specific version of gcc or some other weird tool like openocd or gdb that's hard to hunt down, or is required due to some weird development ephemera you found. Docker makes it a bit easier to compile these requirements and hang on to them painlessly - even across a few years' time lag.
  - sheepshear 3y ago
    It sounds like docker is maybe what got you started saving tools, but if not, how does it compare to your old method (virtual machines or whatever)?
    - cushychicken 3y ago
      I've used VMs, and they work - when you have the same computer. When you upgrade equipment and need to repro an environment, Docker proves to be the lighter lift.

demondemidi 3y ago

This should be titled "A Modern -OPEN SOURCE- C Development Environment". If you work in the embedded space for a large OEM, ODM, or integration house, you won't see any of this ... you will see all commercial environments with big price tags for seats e.g. compilers will be ARMC, Green Hills, IAR; for DAST you'll see tools from Synopsys or Cadence (same for virtual prototyping); lots of ISO compliance tools from hard-to-remember small companies that do that for a living and charge a cool mil to setup and audit ... for CI/CD you will likely see GitLab if not home grown suites. Gnu tools are some of the worst. Containers? 30+ years at this with 10 major contracts with big companies (and dozens of smaller ones) and I've only seen one company use containers and that was for virtual prototyping. C environments move at 1/100th the speed of webdev because product cycles happen in 6-12 months: literally no time to bring up a new system that breaks everything (and for no real benefit).

DoingIsLearning 3y ago
> If you work in the embedded space for a large OEM, ODM, or integration house > Containers? 30+ years at this with 10 major contracts with big companies (and dozens of smaller ones) and I've only seen one company use containers and that was for virtual prototyping. There are _a_lot_ of small and medium size businesses working with embedded devices with limited on-site resources, and those will usually use external contractors. In that case containers are very useful to share an Automated Test environment. The alternative is a long back and forth or spending time on-site supporting teams with wildly varying skill levels. Also as someone else mentioned when an old client asks for a new feature, the ability to take a snapshot in time is a huge time saver, rather than trying to replicate that build environment from scratch.
- demondemidi 3y ago
  I'm highly skeptical of the benefits of containers in the embedded space. The inertia required to set them up and maintain them, and train customers to use them is massive. I'm sure some people benefit somewhere, but in my experience people want a zip file of your code base, platform support package version, and compiler version, ... that's 99% of it. Working with ARC/MSP430/ATMEL/PIC/Cortex-M devices for decades I have rarely seen a codebase over 10 megabytes of customer C code.

manofmanysmiles 3y ago

Having spent a decade building embedded C, its refreshing to see that I'm not the only one who sees the value in doing things well. Every single one of the steps here, though they may seem excessive provide immense value, not at first, but as the project grows, matures, and needs to exist for decades. I am rather surprised at all the negativity here. I assume that it's either few of the people commenting have worked on embedded systems, or the few that do do not have an appreciation for maintaining a large project for the long term. Attitudes like I'm seeing expressed here are reinforcing my desire to get away from embedded, or at last work with people that don't wish to stay stuck in the stone age. I'm not intending to argue here, just surprised and a bit sad at the reactions, and happy that some people, at least at memfault share my values.

randmeerkat 3y ago
> Attitudes like I'm seeing expressed here are reinforcing my desire to get away from embedded, or at last work with people that don't wish to stay stuck in the stone age. I hate to break it to you, but there’s the same problems on the SWE side too. The problem is never the stack, it’s the culture. If you’re tired of embedded, that’s fine, but remember to ask culture questions for your next position.
- manofmanysmiles 3y ago
  That’s disheartening, but not surprising. > remember to ask culture questions for your next position. I will definitely take that under advisement. Any places you recommend I look into?
  - randmeerkat 3y ago
    > That’s disheartening, but not surprising. Don’t be discouraged, it’s just life. > I will definitely take that under advisement. Any places you recommend I look into? Ask yourself what you want? What do you want in a leader? What do you want in a company? Be picky, be patient, if you can, maybe start something yourself. I wish I could tell you what would be the right fit for you, but I can’t. All I can say is don’t lose hope, but at the same time don’t expect too much either. We’re all just trying to figure out this thing called life, whether we’re embedded engineers, SWEs, or even sales for that matter.

nitwit005 3y ago

> Dockerfiles are not stable. A Dockerfile that built just fine yesterday might fail to build today. There are simply too many external dependencies. > Docker is not platform-independent. Especially if you’re running a container on other CPU architectures, e.g., Apple ARM, you’ll notice that some things don’t run. We’ll see this later. And it keeps going on about how Docker doesn't really solve the problem.

zer8k 3y ago

Not bad except for visual studio devcontainers. Absolutely gross solution to a problem I've never faced in over a decade of professional development. I can see docker in some cases (rarely) for C programming. But devcontainers? That's like reaching around your head to touch your nose. I know plenty of people that use them and every time I watch them to try to glean some insight I am left more confused than I started. It seems so stilted. I always get "its a better experience!" but never any explanation why. Like everyone who uses them watched the same Microsoft sponsored youtube video selling them. None of this solves C's only REAL problem (in my opinion) which is the lack of dependency management. Most everything else can be done with a makefile and a half decent editor. No need to step up into vscode if you don't want to. Clang LSPs are basically everywhere and just fine.

torstenvl 3y ago
My solution: git submodules + every project stores its main sources in src/ + Makefile that recursively searches for "src/*.c" files and compiles them to a big ol object collection. It's obviously not infinitely scaleable because you could end up with name conflicts for object files, or some modules might require custom build settings. But it works well enough to nest my own projects 3-4 layers deep without issue.
- duped 3y ago
  git submodules have ruined my life on multiple teams enough to never want them. They're good enough for a dev team of 2-3 but don't scale very well. git subtree can be a bit better. But ultimately you probably want a working package manager.
  - eonwe 3y ago
    I've heard this often. Why don't they scale? I used them for some years for a team of ten or so people who all first had to learn to understand how they worked so might that be the problem?
    - 3y ago

xvilka 3y ago

I wouldn't use Debian or Ubuntu as Docker base for this since they always ship heavily outdated software. Alpine as a base offers slimmer image but also updated tools and libraries, including GCC and Clang. Article speaks about GCC 10 which is prehistoric by today standards.

piaste 3y ago
Can the dev environment and toolchain be affected by Alpine being musl-based?
- xvilka 3y ago
  It's possible, but you can install glibc optionally[1]. [1] https://wiki.alpinelinux.org/wiki/Running_glibc_programs https://wiki.alpinelinux.org/wiki/Running_glibc_programs

emmanueloga_ 3y ago

The setup described is incredibly involved ... I'm doing some ESP32 experiments and plan to investigate PlatformIO which seems to provide solutions to most of the problems described in the OP. PIO supports a bunch of platforms and also provides a way to create your own if necessary [1]. 1: https://docs.platformio.org/en/latest/platforms/creating_platform.html https://docs.platformio.org/en/latest/platforms/creating_pla...

buserror 3y ago

[dead]

travisgriggs 3y ago

I switched from fighting VSCode and plug-in hell to Nova with Seadragon a couple of months ago. At the end of the trial window, I had no problem ponying up money for Nova. I don’t even know where to start on the myriad little ways I like Nova better.

pjmlp 3y ago

Great article, specially by going into unit testing and use of static analysis tooling.

flohofwoe 3y ago

I hope beginners don't get the impression that all this is needed for developing in C. If you want a free (as in beer) and 'good enough' multi-platform solution without tinkering, just use VSCode with 2 extensions: - https://marketplace.visualstudio.com/items?itemName=ms-vscode.cpptools https://marketplace.visualstudio.com/items?itemName=ms-vscod... - https://marketplace.visualstudio.com/items?itemName=ms-vscode.cmake-tools https://marketplace.visualstudio.com/items?itemName=ms-vscod... This gives you a cmake-based IDE-like setup that works across Linux, macOS and Windows (and also allows to build and debug UI applications with the native OS APIs).

brabel 3y ago

`apt install` is just installing a whole lot of utilities without specifying any version. This environment will only last a couple of years (and that's generous because the kind of stuff you're installing, like cmake, gcc, curl, maybe ruby(?) tend to be stable, but at some point one of them will break something you were using). It's the old dilema everyone faces: pin every dependency version to guarantee you have a stable environment that will work in 20 years as long as things can still be downloaded? OR use the latest of everything, making a hugely unstable environment you have to keep fixing every few months, but at least get the latest "security patches" and other improvements (as well as new bugs)?

piaste 3y ago
Yeah, not pinning versions in a container build is bad practice imo. Though, I haven't used Debian-based distros in a while, but does apt actually serve really old versions of its packages? I vaguely seem to remember that you could realistically only `apt install` the last few versions of a package.
- brabel 3y ago
  You can install specific versions of libs with apt[1] but only if that happens to be compatible with your system deps... it's possible to run into trouble where one utility you install requires openssl 3 and another requires the latest version, and then you can't have both libs together easily. But normally, a distro is meant to keep a bunch of utilities with compatible versions for you. I just think that this way of doing things may not be appropriate for building software, and if you look at how Nix does it, for example, you can see that they break up with the traditional Linux distro system and let you have multiple environments with different libraries installed - and you can totally pin everything to make sure it will work forever (or until the sources/binaries can be fetched). [1] https://askubuntu.com/questions/92019/how-to-install-specific-ubuntu-deb-packages-with-exact-version https://askubuntu.com/questions/92019/how-to-install-specifi...
  - piaste 3y ago
    Yeah but I assume that you'd be pinning the base image, in addition to whatever you apt install. If I install, let's say Debian 6, can I use `apt install package=version ` to install the 2011 versions of most packages?

InvOfSmallC 3y ago

I have a side job of teacher at university, sometimes I have to teach C fundamentals. I was looking into giving my students a standard setup. This looks awesome. Have my thanks.

domenkozar 3y ago

That's a mouthful for 14 lines of native development that can generate a dev container using https://devenv.sh https://devenv.sh $ cat devenv.nix { pkgs, ... }: { languages.c.enable = true; packages = [ pkgs.ceedling pkgs.cmake ]; enterShell = '' cmake --version ''; pre-commit.hooks = { clang-format.enable = true; clang-tidy.enable = true; }; } $ devenv shell (Note that pkgs.ceedling has been recently added and will only hit the cache in 6-12h).

physicsguy 3y ago

I just use Spack these days for managing C/C++ dependencies. I don't really see the need for Docker when you're building a binary.

floor_ 3y ago

0% of this is necessary. "Modern" these days seems to just be another word for "bloated" or "bad".

crabbone 3y ago

I don't find none of the things author is using to be useful, or do I ever use them in my C development process. I don't have a need for Docker or any containers for that matter, unless the goal is to deploy in containers. I would never touch VSCode with a ten feet pole. Same goes for CMake -- unless forced to by external circumstances, I will never use it. Even if this environment was set up by someone else for me, I would've found it painfully difficult and uncomfortable to use... so, I don't know why would anyone else want this.