A Modern C Development Environment
interrupt.memfault.com
interrupt.memfault.com
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.
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.
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?
There's not one giant issue with submodules. There are dozens of small annoyances and footguns. I have yet to see a problem that is better solved by git submodules that can't be solved another way.
(1) There's no recursive option; each dependency has to be pulled/pushed/etc. manually.
(2) Each manual pull/push/etc. of a subtree has to be explicitly path-specified and remote-specified.
There's just no easy way to `git subtree pull --prefix=specificdependencysubdir https://github.com/whatever/gadgets main --squash` for each of your dependencies, and each of their dependencies, etc. It's a tedious manual process for everything.
Best case scenario, you make a .PHONY target of `updatesubtrees` and manually keep it up to date with the directory structure and remote URLs of each dependency.
The tool chains for ARM GCC on windows are a real pain to path correctly for multiple systems. Not to mention the same issue for OpenOCD, Debug, etc.
I thought devcontainers were merely a way of telling VSCode to host your dev environment in a Docker container. I'm confused about what distinction you are drawing here.
Right, which is gross. It gets worse when you start talking about using them practically in an enterprise-ish environment. There, they end up being a less effective Xen-style programming interface. It's too bloated for most cases. The distinction I make is building with docker (for cross compilation or whatever) vs hosting your entire dev environment in a container.
I don't really see the difference between just building via docker, and doing static analysis, incremental builds, running tests, etc inside docker. Surely the goal in all these scenarios is the same: a reproducible environment for every developer on the project?
It's hard to take stuff out of a running container; and it's hard to access files/programs on the host from within the container.
There may be advantages to running inside a container; but it largely feels like when there are easier ways for quickly making programs available to the host (e.g. virtual environments, or asdf version manager), then most tools aim for that first.
Bind mounts let you easily move files in/out of the container (and are already set up by devcontainers). And the whole point is to _not_ access programs on the host, you want that isolation so that the environment is reproducible and everything you need to build is defined in the dev container.
It just needs your build toolchain and libs.. you don't need to use the shell from the container to run random unix utils or curl for instance.
* granted I did just spend half a day last week figuring out that WSL environment variables are not correctly applied to the containerEnv, but otherwise they've been solid
Bloated how? Which cases?
Any C app (or even Python app, since python libs like to depend on C libraries) with non-trivial dependencies get very annoying to configure across a range of distros (even worse if you include MacOS and/or Windows).
`sudo apt install libpng-dev` vs `sudo dnf libpng-devel` etc.
Rather than document and test all those different configs, devcontainers is a really easy way to avoid this pain for example applications or ones that will only ever ship to one distro/OS. And if you're running on Linux atleast, there's literally no overhead (containers are just processes tagged with C-groups, after all).
cgroups require code to implement. This is overhead. "Literally" is not the word you should be using. Perhaps "little" overhead or "minimal" overhead?
IMO I'm using it correctly here though, let me explain.
Overhead is originally a business term that refers to an ongoing cost. Yes there is a small amount of code in the kernel that has to run, but my naive understanding is that this code also runs for processes that are not in a container (the kernel still needs to check whether the process is in a namespace or not). Additionally, I've never seen a benchmark that shows a workload performing worse when cgroups are applied. I'm happy to be proven wrong here but if this is the case, then there is no ongoing cost (and thus no overhead).
Doing it inside a container solves the portability problem, but you're still using a Linux distribution's package manager to get the dependencies of your project, which makes no sense to me at a fundamental level, even if it "works" in practice.
Is vendoring the only somewhat sane way of doing dependency management in C?
I would hope that tools like conan and vcpkg solve this now on the developer side? I don't have much experience with them though.
You still have to deal with libc though, which means you likely need to containerize to avoid issues with old versions or distros that use something other than glibc (musl or bionic, for example).
It's a lot more complex with C/C++ to build fully static binaries than it is in something like rust or GoLang.
I'd juxtapose these two sentences.
As I understand things. Those who know Nix swear by it. You can declare a development environment which will provide the toolchain and the libraries you need to build your software.
Some things do seem inelegant about Docker containers. e.g. Building the images with Dockerfiles feels fragile. Running containers means high friction to accessing the build environment from the host machine.
Those downsides aside, AFAIU the VSCode devcontainers aim to provide that "wow it just works" experience that the Nix people love, without having to pay the steep learning curve of learning Nix.
I thought this too for a long time, but the more I'm exposed to languages with "proper" dependency management the more I appreciate the C way of just copying external library sources into the project (and I only consider libraries which make this easy, e.g. if they come with their own complex build system files they already lost - just give me a bunch of headers and source files, and maybe a readme with a list of configuration defines).
And why is that? I find it really cumbersome.
Those who tried it and swear by it.
Those who tried it and swear at it along with words like 'never again'.
Those who tried it, and avoid it in favor of Guix, but would use Nix if they had to.
nix on the other hand, I loved the concept and idea, but it was just too much of a 'stop sign' followed by 'we don't do that kind of user activity here' to be usable. I tried for a few weeks to bend our wills together, but the systems' will won and I walked away.
I suspect my experience with guix would have been remarkably similar if I hadn't been put off by the speed - I love scheme, but guile has always seemed the second slowest implementation ever, and I suspected that was the cause for it taking so long to do anything in guix.
This is only usually a problem if you want to download something large or do a large update though. If you're just downloading a small program or you update your system frequently, it's quite reasonable to use.
As far as the "stop sign", I have never really run into that with Guix, and I did run into that with Nix. The fact that Scheme - unlike the Nix language - is not purely functional, I think encourages users to do what they want, even if it goes against the spirit of the functional package manager.
Please don't take this as "you're wrong" or to somehow invalidate your experience. In the two years of running Guix as my main system, the only time I've thought something was slow was in building Chromium from source (which took all night to compile). Everything else I never noticed. Certainly not downloads. Those were fine for me both in the US and in Europe. Your experience contrasts so sharply with mine, I wonder what the difference is?
Sometimes downloads are fine though. I think it's an issue of load on the servers that will cause downloads to be slow sometimes.
The contractors have a huge productivity advantage out of the gate - modern hardware, any software, no mandatory VPN that blocks genuinely useful websites (MDN!).
Of course Git kinda sucks and isn't good at hosting toolchains. So I'm putting a heavy emphasis on "should".
For several decades, I have never compiled any C project otherwise than with auto-generated dependencies between files, which are generated by the compiler and used by make.
I never write by hand dependencies for a makefile. (I also never write by hand the list of source files, but I let make search for them and choose the appropriate compiler)
It is true that many open-source projects have horrible makefiles, but I have never understood why anyone has written such makefiles, when the GNU make manual explains the right way and that explanation already existed at least a quarter of a century ago.
Care to hear about our lord and saviour Meson?
Both of your quoted problems are mutually incompatible: dependency management isn't the job of the compiler, it's a job for the build or host system. If you want to keep writing makefiles, be prepared to write your own `wget` and `git` invocations to download subprojects.
Meanwhile, Meson solves the dependency management problem in a way that makes both developers and system integrators/distributions happy. It forces you to make a project that doesn't have broken inter-file or header dependency chains and cleans up all the clutter and cruft of a makefile written for any non-trivial project, while making it trivial to integrate other meson projects into your build, let other people integrate your project into theirs, and provides all of the toggles and environment variables distribution developers need to package your library properly. You can really have your cake and eat it too.
Docker vs. devcontainers: You got my point. It isn't about trying to force people to use devcontainers and vscode, it's about maintaining and sharing a development environment. You could just open a shell in this container and swap the base image out for whatever you need (also pointed out in the article). I myself also don't use vscode devcontainers but just exec into the running container and, e.g., use docker compose (or podman or whatever works best) :)
EDIT: The reason for showcasing devcontainers is that you get an IDE with code completion, format on save and all the other goodies "for free", whereas any plain docker or nix setup requires that you do this on your own. In my career, I've seen way too many people editing code in notepad or notepad++, making tons of mistakes that can be avoided by whatever IDE. I'm not saying vscode is best, I'm saying right now it is the easiest IDE to set up.
It is recommended at work now, where I also can use "the old way" which is a series of Makefiles. I've never had a problem with the Makefiles, but they've been hand-tuned for a few decades, and errors would be reported immediately by the build server. They check if you have the right compilers and then just work. Contrast this with Docker, where you always have the right compilers and they only work sometimes.
While using Docker, if even one source file changes while the compilation is happening, the VM will simply hang and refuse to compile or accept any break keystroke. Outside of Docker, a file change sometimes works without error and sometimes you'll cause a minor problem that a new iteration of "make <whatever>" fixes in a few seconds. Worst case? "make clean", "make <whatever>", no reboot required.
After force quitting the Docker-based build, I try "machine stop" and "machine start" but often encounter errors and need to reboot my machine and/or reinstall Docker, such as this gem from last week, "No connection could be made because the target machine actively refused it."
I don't know if Docker has an equivalent to "make extraclean" or "make distclean" or "sudo cut the bullshit && let me use you again", so I'm already uncomfortable restarting a build after rebooting/reinstalling. (That you need to manually delete container directories after uninstalling is also troubling.) I know some data are stored in the container in a mixed-persistence way that uses the existing filesystem. It's confusing to me why some generated output (.pdb, .exe, .dll) are accessible outside the container while others (.o) are evidently not used if you decide later to rebuild without Docker. Thus, the difference when switching is often recompiling 5 files in a few seconds vs 500+ in a few minutes, so there's a short-term incentive to try to keep using Docker, where I then waste time trying to solve Docker instead of just recompiling with the old method. Any semblance of "Flow" I have after getting a Docker error gets annihilated.
If our local container server goes down (it's not often but has happened), I am unable to build because some of our dependencies aren't FOSS/widely available.
I've had issues related to services, prerequisites, permissions, mounts, certificates, massive network login delays... When I hear the constant praise for containers, it gives me pangs of imposter syndrome, because my experience has been awful and mentally taxing. I find I'm constantly fixing tools instead of using them.
I can't necessarily blame Docker, but twice in the past 3 years I've needed to install a fresh OS within a week after installing it because of the problems above.
Docker's main selling point? It fixes a problem we don't really have. Every developer at my company has essentially the same computer---an overpowered Ryzen/Quadro combo in a black tower with a small collection of preinstalled essentials like MSVC bintools, VCS software, network drives preconfigured---unless they specifically request another for build purposes, i.e. Mac or Sun. In the latter case, that developer (or small group of developers) is in charge of builds on that host OS. In the one place it matters, we have one version of a compiler expected in a specific directory, and this is well-documented and changes once every few years.
It's possible I completely misunderstand Docker or have a misconfigured system (whatever THAT means, I thought the whole point was to eliminate problems caused by local customizations), but for anyone to tout it as fool-proof would mean they have severely underestimated the technical (in)abilities of fools.
Docker, to me, often feels like bringing in and using a CNC machine when all I usually need is a sharpening stone and chisel.
-----
Also, I would be quite uncomfortable using GitHub Actions to compile C for a microcontroller. There's simply too long of a delay between changing a config YAML and getting an error, fixing it, waiting for the next error. Plus, despite the "low overhead" of Docker, if you do this long enough on GitHub (especially with a non-Linux host OS) you will run into server fees.
And after you set up a GitHub Action, are you writing in VS Code, waiting for the remote computer to compile, downloading the artifact, syncing that with VS Code so you can debug, flashing to the target with your own set of (locally installed) tools, and finally debugging?
Contrast that with a local install... Edit. Save. "make", "make flash", gdb. In 20% of the time, with no server costs.
I.e., you can point a .devcontainer at a Dockerfile that you've already got working for your environment and specify standard configurations for environment variables, vscode extensions, and other bootstrap configurations so that the startup friction for a new developer working on the code is reduced to the minimum and the manual steps they need to compete to get started are documented and standardised in the devcontainer format, but you don't lose anything by doing so.
First environmental category: your dev environment itself.
What platform are you using? What architecture are you using? Do you need a VM? How will you mount filesystems? How will you handle networking - through the VM or on the native host? How will you handle HTTPS proxies - on the docker client, on the docker server, in the VM? Do you need a custom DNS resolver? Do you need additional applications for your platform, like AWS or GCP CLI tools and credentials? Do you need more applications, some of which may have specific version requirements (for example, Homebrew famously does not support old versions of software)?
Second environmental category: CI/CD.
How should I do a build, test, and deploy from my laptop? How should I do a build, test, and deploy from a CI/CD server? How can I make sure I get the same result from either? How can I reduce the number of dependencies in the deployed form, without getting different results at runtime? How can I re-use things from my local machine in the CI/CD so that I don't have to maintain two different ways of doing the same thing?
- In the best case: you have no problems at all, and everything works automatically.
- In the worst case: one of a hundred different things can break your dev environment. You end up spending an inordinate amount of time just "maintaining your dev environment", rather than writing application code. And the more developers there are, the higher the probability of time is spent on "environment work" rather than "making the product".
- Besides all of that dev environment work, you end up replicating your whole process in a completely different CI/CD system, and now you're maintaining two separate yet identical things.
A solution to all of these environmental factors combined is Devcontainers: https://containers.dev/overview Because it's one standard, all sorts of tools can now take advantage of it. This means different devs can use different tools to solve the same problem with the same config file.
Bazel solves this really nicely, I know some people have strong opinions on it but I cannot recommend it enough
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.
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.
> remember to ask culture questions for your next position.
I will definitely take that under advisement. Any places you recommend I look into?
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.
Disagree. I had to learn make for my first job. I found two ways to manage dependencies that are probably the most common, and the limitations. There really isn't a method that is perfect; I don't know if dependencies can be done (even outside of C) without occasionally rebuilding.
The methods that I've seen rely on using the compiler to generate .h dependencies via the preprocess command. This can be done with gcc / cygwin for cross compilation, or with the native compiler. I'll explain.
Method 1: the "better" method. Generate dependencies for your header files at make invocation, before compile step. This is more robust, but outside of very small projects, this can add a ton of time to the build.
Method 2: the faster, more common method. Generate dependencies as a side effect of the build. When you compile, you use the previous dependencies. A new dependency file is generated for next time.
They both have limitations. Method 2 can detect changes in the header files included from C files, but not headers included from H files. Method 2 can detect changes in header chain, but not all the time. I think it's the files that the headers include, those includes from that file don't get updated, but it's been a while since I've read the paper.
Anyway neither method is that hard. You use gcc to generate dependencies for each file, then combine into one file (or you may create .d files, but for some reason a single file is common). That's it.
Otherwise, add a step to compilation (some compilers may have a build in "byproduct" command). Every time you generate .c there's also .d. When you compile, you use the previous *.d file.
Yes you need to know make, and this is an intermediate-to-advanced make task, but this is true for any build system! Entry level is a user that usually just adapts a build from the engineer experienced with the build system.
When developing for a very small project the generate dependency first method was used. It's more complete. Still added an annoying amount of time to the build ~20-60 sec.
For our main project (which also might be considered fairly small, relatively) this method ends up being too time consuming. So the generate dependencies as a byproduct of build method is typically employed, including by: a completely separate team, a competent supplier, and recommended by our compiler company.
Honestly, once you know, you're golden:
The generate ahead can be done with gcc (I think g++ is typically employed) via the preprocess command. You create a rule to generate all *.d first, and combine into one file (this may not be necessary).
To generate as a byproduct, you simply add a command to your compile rule.
That's it. Can be described in one line. I can't recall offhand, but you will need to figure out how to include the dependency files and the formats may need fine tuning. This isn't asking very much.
I saw a really good document out there, and interestingly our supplier copied it almost verbatim. Our build ended up being somewhat similar. So that sweet, sweet doc is out there, you just gotta find it.
I'd say if one has the sort of problems TFA says it addresses, then go for their solution. But if one does not see any problem a priori, then they should go for the simplest thing that could possibly work. One can always reconsider things later; but if one goes for that more sophisticated solution first, and then realize that it was actually not need, they've wasted their time - and perhaps introduced problems that would never had happened without.
Don't be fooled by "modern" anything - too often it introduces new problems while solving old problems. "Stone age" can also mean battle-tested and rock-solid solutions.
Nothing author describes is applicable for a large project or a long-term project or both.
He chose one of the worst editors available, and decided to incorporate it into environment setup. Any long-term or large project will have multiple people working on it. A fraction will find the crappy editor the author decided to use useful, but most will want something better. Most people with development experience will want to set up their environment in the way comfortable for them, this setup is asking you to jump through too many hoops, none of which bring any value.
Same goes for CMake -- I've worked on multiple large C projects. None used an off-the-shelf build tool like CMake. These tools are inadequate for large-scale projects. (But, lets give the author credit here, he never claimed that his project was large or long-term). Still, I had never found CMake to be useful, nor for small nor for big projects. Whenever I had to work on a project that used CMake, it was a major pain.
It is common to test stuff in containers during development. But, it's also more common the more lazy and less insightful the programmer is / intends to be. In my experience, better programmers usually set up their environment in such a way that they don't have to deal with the container nonsense, as it gets in the way of debugging and a bunch of other tools useful to interact / understand the program being tested.
So... maybe containers for a smoke test. But, if you plan on going long term... that's just not going to cut it. You need a proper environment where you have comfortable access to your program.
...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.
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.
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
of course you need a testing framework
if (!strcmp(argv[1], "--run-tests")) return run_tests();
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")));
...
}
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
If you're going to learn a bunch of modern tooling and start a green field project that justifies that complexity, C is generally a poor choice. Learn a modern language.
I use C somewhat regularly, including for kernel stuff, embedded, and legacy code.
Mostly, though, when I use C, it's because I'm doing a small thing that I need to be very fast, and I haven't yet bothered to get comfortable with Rust.
on your other points i mostly agree, except that if i write a library in any popular 'modern' language, it can only be called from that language, which seems like a missed opportunity
and when i went back and compared development time logs, the development speed advantages of modern languages seem to be only a factor of 2 or 3 over c, once i get beyond a few hundred lines
which i guess is why linux, firefox, cpython, gcc, apache, poppler, libvte, and so on are written in c or occasionally c++. it's not because the authors didn't know about common lisp, scheme, ml, smalltalk, and so on, or couldn't figure out how to write a garbage collector
rust and some other unpopular modern languages look like they might change that situation (nim, zig, koka, a couple of others i can't think of right now)
Yeah, the "C is the universal ABI" problem is... annoying. Hopefully something safer eventually replaces it in that niche.
Also, I think the main reason I use a lot of the tools I do is just "suck cost fallacy".
what the fuck is it with these people that they flagged your comment upthread
Are you using C99 features? I find the "new" features extremely enjoyable, it feels like a different language compared to C89 or the common C/C++ subset.
I don't say any of this as a dig at C, but at ~50 years old, it definitely shows its age.
See https://www.urbandictionary.com/define.php?term=Gatekeeping
We always talk about how good engineers "choose the right tool for the job". I don't think expressing an opinion on what the right kind of job is for a particular tool should be out of bounds. (Setting aside whether the opinion is correct or not.)
What a bad faith interpretation.
It's advice based on the poster's experience, stated with both qualification and good humor. You are free to ignore it. I appreciated it.
The fact that you don't see this as problematic, is problematic.
thus hegemonic institutions reinscribe the kyriarchy generation after generation by perpetuating a hierarchical opposition between "knowledge" and so-called "ignorance", which is socially constructed to be inferior, less than, but which serves the purpose of distinguishing the graduates of elite institutions (to which access is mediated by the financial privilege of the bourgeoisie) from the subaltern underclass; thus "knowledge" serves the interests of capitalism by reproducing oppressive class divisions, enabling the continued exploitation of the working class
what could be more problematic than that?
but if you're interested in learning something and not just playing word games to gain status by putting others down, i problematically mansplained what you're missing in https://news.ycombinator.com/item?id=37083233
The advice is common enough that it has a wikipedia page: https://en.wikipedia.org/wiki/KISS_principle.
There is no gatekeeping. There is a suggestion that C is best used for projects that have builds no more complex than a Makefile configuration. There is explicitly no ~judgement~ limit on what ~kink~ text editor one may use to edit the files.
I'm guilty as charged. The advice is not discouraging unless you really want it to be.
If someone wants to do that anyway, I am going to be perplexed that C was the language choice rather than golang or rust, and perhaps worried about C being a footgun WRT security, but whatever.
If you work on a C project, you need to be ready to have to edit source code, at least minimally, from an environment that doesn't have GUI. You will have to interact with pagers, man readers, readline a lot -- it's a lot more convenient if your editor works in the same way as those tool.
You are just creating unnecessary problems when you use VSCode or a similar editor. And I cannot think about a single benefit that would come from using it. Beside other things, it's just a crappy text editor... the only thing that's going on for it is that it's a Web browser application... which is kinda worthless when it comes to a typical C project.
Seemed perfectly modern for the mid-90's using DG/UX.
Apparently plenty of people don't have a clue of many of those environments used to be.
Sorry buddy, you might believe Makefiles are fine only if you are not aware of the most basic requirements of a build system. CMake does stuff like running sanity checks on libraries, configure them for you with minimal effort, and even add platform-specific configuration easily. Did you know that cmake started as a Makefile generator? Why do you think people need that?
Makefiles alone were never enough, as the development of tools such as the autotools family demonstrated decades ago. Claiming otherwise just seems naive flexing from someone who has no real world experience whatsoever.
I like make myself, but I’m honest enough to acknowledge that the whole autotools suite (autoconf/automake) was born to, essentially, generate makefiles.
Which is not 100% make’s complexity’s fault though… the toolchains have their own complexity (even more so when a project must build across platforms)…
So, let's say we have a project. For whatever technical (or social, historical, religious...) reason, C is chosen as the right language.
Why does that imply that the programmers on that project should therefore write that C code in a terminal, with no linter, code formatter, static analysis, test runner, etc.?
Teams can use a combination of different IDEs and run the tools at different levels or their pipelines, which necessitate that they be automatable (and not GUI only).
Presumably they were busy generating billions of dollars of revenue.
Also, I'll add that automated testing was definitely not as much of a thing in 2003 as it is in 2023.
Eg while I enjoy understanding all the layers of software in a computer and am perfectly comfortable with vim and a makefile (although I prefer vscode and cmake), most of the other developers I work with are just as competent with C, but can't really function if they can't use visual studio. To them visual studio is the basic tool and vim+make are advanced tools.
That said, Vim has some IDE-like features, moreso for C (by default) than some other languages.
Again, the point is that C is complicated and hard to work with as you scale up into a bigger project, not that my tools are better than your tools.
There are, of course, always exceptions.
GCC searches by default in /usr/include and friends, (and a similar set of paths for library paths), meaning that one random library you downloaded 11 years ago is now perpetually on your search path.
It's for C/C++ as author says, not just for C. And even if you're using Qt and write mostly QML you still need some C++ and it's much easier with code completion. I'd rather use VSCode than Qt Creator for that and I'm certainly not going back to vim.
I also write Free Pascal using Lazarus, an IDE which actually understands the language at a deep level.
The experience writing the latter is way *WAY* better than the former and my opinion to that isn't "just write more in Free Pascal" but "i want an IDE for C that is at least as good as Lazarus is for Free Pascal".
I want a C IDE that, among others:
1. Can understand the code so that when i, e.g., want to rename the identifier "foo" it doesn't try to rename it as a keyword but knows if it refers to a local variable, global variable or struct member and only update references to that.
2. Can understand the code so that if i use a symbol defined in a header file that the current module doesn't include by itself it can put it in the includes section automatically (or at least ask me to) instead of waiting for the compiler to fail. If there is some conflict (e.g. because the symbol definition depends on macros or whatever) it should be able to understand that.
3. Can understand the code so that it can move structs, functions, etc around in modules and update header files and their uses in other modules automatically.
4. Can understand the code so that it can convert a struct defined in a header file to an opaque struct and vice versa, for the former being able to tell me which existing code would break and offer fixes (e.g. automatically creating accessor functions for the members).
5. Can understand the code so that it can expand macros in place visually, allow me to edit the macros expanded in-place while actually modifying the header file (or wherever the macro is defined) and also quickly tell me where the macro is used in other places.
6. Can understand the code so that it can convert code to functions, expand functions inline (with any local variables being placed at a decent position and any conflicts handled - it can ask for example if it sees the inline code to use "for (i=1; i<10;" and the existing code also has a "int i" if it should reuse the "int i" or replace it with heuristics that provide decent defaults), add/remove arguments (with automatic updates wherever they are used), etc.
7. Can understand the code so that one can create queries like "replace all string literals to non-static functions whose name matches the '^foo_.*$' regex with calls to macro 'TXT' and the same string literal as the parameter to macro".
8. Has a debugger that works with all the basics (breakpoints, step in/through/out, watches, etc) and...
9. The debugger can modify a variable while the program is running.
10. The debugger can make function calls while the program is running.
11. The debugger can modify a function while the program is running (any new calls are done to that function).
12. The debugger can watch data over time and be able to display values in various means like various graph types.
13. The debugger can tell you where (in code) some use-after-free was originally allocated and then where it was freed and where it was used, all with nicely shown arrows, hyperlinks and graphics directly inside the editor instead of you having to manually parse (in your head) some callstack. Similar for other types of errors like accessing invalid pointers, array data out of range (should tell you both the range and the accessed index where that can be statically inferred), etc.
14. The debugger can put conditional breakpoints which:
14a. Can call functions defined in the program.
14b. Can check if the breakpoint comes from a specific callstack (e.g. break if function "foo" is called from "bar" but not from "baz").
14c. Can access local variables and arguments up the callstack (obviously the breakpoint will only break where that is possible).
15. There is a profiler that works and...
16. The profiler can create call-based profiles (think gprof) and statistics-based profiles (think perf).
17. The profiler can record the full callstack instead of just the function name.
18. The profiler can create full call diagrams (see Luke Stackwalker[0] as an example) as well as flamegraphs (see some perl script for perf i don't remember).
19. The profiler can keep track not only where* but also when* a sample was taken so it can create profile timelines. Actually just have it do everything i had a profiler i wrote some time ago for Free Pascal[1], including be able to be instrumented by the running program, filter via thread, call stack depth, etc.
20. The profiler can call functions in the profiled program to create additional profile (e.g. if you want to count how many files are opened or how many rays your raytracer is casting or whatever so you can use the full profiler functionality instead of hacking up your own)
21. There is a static analysis tool that works and...
22. ...works like whatever Xcode's integration with Clang's analyzer is, i do not have much experience with those but i remember using it a couple of times years ago and thinking it was neat. I haven't seen any other graphical integration of a code analysis tool, pretty much every other analyzer feels like compiler warnings++. More of the graphical approach and less of the warnings++ approach please.
23. There is some form of project management / build tool / whatever that the IDE uses and...
24. The IDE can let you setup various "configurations" for build options (including preprocessor defines, which files/objects/libraries are to be included, etc) that can be mixed and matched at will (e.g. a "lightweight" and "full" configuration set could be mixed with a "win32" and "linux" configuration set with the latter relying on the "unix" configuration and none of those would need you to duplicate any information).
25. The IDE can know about libraries, be able to locate them as well as place them in appropriate locations when you are building a library. Libraries should be able to be built as both statically and dynamically linked if that is needed. If a library A relies on another library B and a program uses library A it should not need to also specify library B too - in the exceptional case where that is needed (e.g. there are alternative versions of library B) it should allow that but it should not be necessary.
26. Setting up the above should not need to be done via arcane text files but via a nice GUI that doesn't hate the user - e.g. using a library should not need you to type it's name but allow you to check next to its name in a listbox with checkboxes (with name filtering and categories). It should also know about different system libraries for the same thing (e.g. OpenGL in Windows, Linux and Mac is accessed via different ways). This should be configurable, not hardcoded - a custom library should also be able to use that functionality. Note that all of this can be stored in text files (e.g. for easier VCS support) but not needed.
27. More of a #26b but i think it deserves its own point: in addition the IDE should have deep knowledge of what a library offers and like #2 if it knows a symbol being offered by a library it should automatically add it to your project's requirements.
28. Again more of a #27b but also a #2b: it should be able to clean up any unused stuff (either automatic or explicitly). In total i should, e.g, be able to use OpenGL by typing "gl", pressing the auto-complete key (ctrl+space or whatever) and have the IDE suggest all the "gl" prefixed functions like "glClear", then once i select "glClear" (or whatever), the IDE adds the #include <GL/gl.h> header and the libgl library in the dependencies. If i press Ctrl-Z to undo that, the header files and library dependencies (if added) will be removed. If i press Ctrl+S to save or some other key to cleanup the project (depending on the configuration), any unused headers and libraries should be removed.
I could write for more but basically i'd like an IDE (i haven't touched topics like VCS support and how i'd like to be able to see and use different version of the code from inside the IDE - like e.g. go back in time to a different function while the debugger is running - or anything that has to do with GUIs) that is smart and helps me get rid of all the manual drudge,
(also FWIW little of the above is provided by Lazarus and i'd also like Lazarus to do all that where it makes sense but it still does more than pretty much any C IDE i've used)
On Linux (which is my main OS these days) pretty much all options involve a text editor with some plugin/addon to somehow understand C plus the ability to call a makefile or some other command. Of all those Kate (KDE's "advanced" text editor) with an LSP plugin and a Clang-based LSP seems to be good enough.
Though it is really more of a "least bad" than "actually good" situation.
> On Linux (which is my main OS these days) pretty much all options involve a text editor
You obviously haven't looked hard enough. CLion fulfills a decent amount of what you're looking for. https://www.jetbrains.com/clion/
A lot more limited, but still much more capable as an IDE than text editors is KDevelop, for example your request here :
> (i haven't touched topics like VCS support and how i'd like to be able to see and use different version of the code from inside the IDE - like e.g. go back in time to a different function while the debugger is running - or anything that has to do with GUIs)
https://kdevelop.org/features/
> An especially useful feature is the Annotate border, which shows who last changed a line and when. Showing the diff which introduced this change is just one click away!
Also example snippet of the debugging integration :
> You can also hover the mouse over a symbol in your code, e.g. a variable; KDevelop will then show the current value of that symbol and offer to stop the program during execution the next time this variable's value changes.
https://docs.kde.org/trunk5/en/kdevelop/kdevelop/debugging-p...
CLion has the problem of being a proprietary program that requires online validation, which is a big hard no for me.
Also IMO the fact that you point out KDevelop being able to show a per-line commit and the current value of a variable, both being among the minimum you can expect from an IDE tell me you didn't read what i wrote that i wanted, so by extension i doubt CLion also does anything close to what i wrote.
I don't "just" expect "some" debugger integration or "some" VCS integration, i explicitly wrote things like the debugger being able to call a function in the running program or modify a function while the program is called or being able to replace the current function with an older version of the function taken out of VCS. Among a ton of other things.
What you show KDevelop to do aren't anything special, even non-IDE "programmers' text editors" can do them.
After all i still have and can use Borland C++ 5, Delphi 2 and C++ Builder 1 to this day without requiring any sort of connection or having Borland's permission to use the software i bought. I can't do the same with CLion.
[0] CLion relies a lot more than Borland on external tools like GCC, CMake, GDB, etc meaning that not only it most likely does not provide all the integrated functionality i mentioned but there is also a very high chance it will stop working at some point as its dependencies are changing so you do need to rely on JetBrains to keep it up to date without having access to the source code.
I wrote some simple C a while ago and my go to IDE (which ostensibly says it supports C/C++ out of the box) wasn’t working, and since this was just a dabble, I was really not interested in fighting the IDE.
And, mind, I haven’t touched C in 20 years.
So I fired up Xcode. And, boy, that was easy. For my silly thing, I fat fingered and left thumbed my way to success.
No doubt Xcode has its critics and limits, but for my 3 hour project, I got to focus on my code and not the IDE.
I have another, more substantial pure C, not Mac specific, project I’m thinking of starting, and I’ll go with Xcode until it fails me.
XCode has to carry a lot on its shoulders these days - C, c++, objective c, SWIFT and a lot of GUI editors, so it's impressive for what it is.
But it can easily support simple c/c++ projects, I've actually developed apps there and then ran them on linux, sometimes with the odd #ifdef to make it compiles on linux, but the dev experience on XCode is better for me than anything I can get on linux.
> 11. The debugger can modify a function while the program is running (any new calls are done to that function).
Another words: hot code reloading / swapping [1].
And I would add:
> You record a failure once, then debug the recording, deterministically, as many times as you want. The same execution is replayed every time. [2]
[1] e.g. https://github.com/ddovod/jet-live, https://github.com/crosire/blink, https://github.com/ziglang/zig/issues/68
Indeed, though without the use of external libraries, be for C and integrated seamlessly into the IDE - and it needs to work on Linux since that is what i'm using :-) (i've used MSVC's edit-and-run or whatever is called at the past though it was kinda finicky if it worked or not).
Really. I'm not kidding. It's all there. Not for everybody but /clearly/ very much for you. (Unless you move the incredibly complex goalpost you've set up here).
It has a learning curve to configure and to use but if the above 28 is what you want as you say you /can/ have them all.
All of them. For real. Working. It's on you now.
29. vim or emacs keybindings if you want that.
If so i'd be impressed - and TBH ~17 years ago i did use Eclipse CDE and found it superior for C and even C++ code compared to what i saw people praise MSVC for (though MSVC's debugger was better than the GDB front-end functionality Eclipse CDE provided), so i don't think it is unlikely. I do remember it having some neat integration with Trac back then too. I mainly stopped using it because the computer i had at the time struggled to run both Eclipse and Mozilla at the same time :-P. But ~17 years ago i always praised it with the only annoyance (resource usage aside) being that weird "workspace" approach, but that was minor.
I didn't think much about it because it seemed to have fallen out of fashion since then so i thought it is just limping along.
I think i'll be trying it out then :-) perhaps it is time to go back to Eclipse CDT if that is the case.
EDIT: eh, tried it, not impressed. First of all Eclipse crashes or hangs almost every time i try to edit the settings.
Then i tried to make a test library, "librola" (random name) to be used by a program "rolathing". First i made the library using the managed C project with the "Linux GCC" toolchain that was already available. Typed some methods "int rola_init" (dummy, sets some static initialized variable to 1), "int rola_gimme" (returns 42) and "void rola_shutdown" (sets the initialized variable to 0).
1. I forgot to mention it in the above but Lazarus and other IDEs already have this anyway and it seems Eclipse CDT also has it, except it doesn't work: i tried to have the IDE generate the bodies for these functions in a C file (that didn't exist yet) using the "Implement methods" command that seemed the most appropriate (and i couldn't find anything else anyway) but that didn't work. I thought it was because there wasn't a C file so i made an empty one with the same name as the header file but again it didn't work - even after adding an #include in the C file for the header file it didn't seem to match the two. So i typed these by hand even though i believe it should either use the C file with the same name as the H file (a common use) or at least ask me.
2. I made a C program with managed C project and added a new "main.c" file to it. I typed "rol" and pressed ctrl+space to see any suggestions and there were none, so it basically failed #2 and #28 above. I typed the code manually, used printf to print out the return value of "rola_gimme" and even after saving there were no errors or warnings at all even though the C file had no include files at all.
3. Tried to compile and as expected, it failed. There were no quick-fixes or anything else i could do from inside the IDE - there was an "info" message that i should include stdio.h to get the printf definition but the IDE wouldn't help there by adding it itself, i had to manually type the code. And TBH most likely that message came from the compiler and the IDE was oblivious to it anyway. Obviously no message about which file to include to get the rola_init, rola_gimme and rola_shutdown definitions, let alone doing those for me.
I lost interest at that point because it not only was unstable but also failed at the first thing i tried that would show the IDE really understood the source code. Note that this whole "automatically add header files" isn't even something i came up with, i remember a trial version of C++ Builder i tried years ago to do that and while i didn't check to see if it only does it for the header files that come with it or also for your own libraries, the latter would be an obvious thing to do anyway as the library was already part of the workspace and thus known to the IDE - and Eclipse didn't do either anyway.
But just in case, i tried to at least try the debugger so i thought to add the reference manually - which i did but Eclipse crashed every time i pressed the "Apply and close" button. However restarting it seemed to have the setting applied anyway so i could at least try the debugger. And at the end i couldn't figure out how to convince Eclipse to use the shared library project next to the program project, no matter what i tried (i'm sure there is a way but IMO all i should have to do is, as i wrote in #26, check the library's name in a listbox with all the available libraries - and FWIW there was such a thing but it did absolutely nothing, Eclipse only started realizing there is a library somewhere when i started adding in paths, etc, manually but i failed to make it build).
So at least i wrote a "int foo() { return 42; }" (in more than one line :-P) in main.c and then have an endless loop in "main" and run the program under the debugger. The program wrote a bunch of "42"s in the stdout so i put a breakpoint in "return 42;" and modified it to "return 48;" - then continued and... nothing happened, it kept outputing "42". I tried to rebuild the "current source file" and even "rebuild all" but it didn't change, i had to restart the program, thus failing (as far as i can tell) #11.
On a semi-positive side i made a "int lala(int x, int y) { return x*y; }" and the debugger was able to run this function, but then when i tried it with something a little more practical like implementing a very simple strlen "int lala(char* s){ int l = 0; for (;*s;++s,++l); return l; }" it failed with some weird errors.
So, eh, i don't think Eclipse CDT is it :-P.
You'll have to set paths on the installation or project so it knows where the relevant libraries and headers are. You won't configure it all correctly in the first week.
If you do give it a go, use a makefile project. If you're using something else to build, just have the call to that in the Makefile and nothing much else. Maybe it does cmake etc now? Haven't tried. I only use it occasionally nowadays. Brilliant for any refactor.
>So, eh, i don't think Eclipse CDT is it :-P.
Don't confuse, "I didn't get it to work first time with very little effort" "does not work" Also note that like any complex tool, once you've worked it out, which takes time, you don't have to do that again. Like the people who say vi is garbage because you can't quit.
If you don't spend the time and give up early, that's fine too and shows you how much you do or don't want these things and /any/ answer there is by definition correct.
Edit: Editing a post above a response with wholly new info is a pain, don't do that. Just hit reply.
I don't confuse the two, the program didn't do what i explicitly wrote in my post. If you think it can do what i asked, please explain how, because right now from what i can see it fails to do what i want from it. I didn't try everything i mentioned because it failed at pretty much everything i tried from the very first thing, so it didn't give me any confidence to keep on trying.
Also you seem to misunderstand something important even from my initial post: almost everything i wrote can be done by stringing together various tools and/or have various workaround, even the "modify code while it runs" could be done by using one of the libraries or tools mentioned elsewhere.
But the point is having the IDE actually do all that in a single place and with good UX (for example i didn't mentioned the part about checking a library's name in a listbox of libraries in a project's settings for fun, i mentioned because i expect at least that sort of user experience and convenience for the user! Eclipse CDE fails at that part because it needs all filling all sorts of forms in various places to see the library - my requirement wont be met by ignoring the requirement, the entire point of it was to request good user experience).
It is all about having a good user experience, if the program fails at that, it fails at the core of what i asked.
> Edit: Editing a post above a response with wholly new info is a pain, don't do that. Just hit reply.
When i edited the post there wasn't any reply, you replied while i was typing the edit.
You don't want what you said you wanted because you won't do the work to get it. It's not even that much work tbh. That's fine. It does work for me and the "user experience" is fine. I'm not associated with the project, nor pushing anything. You can pretend it's because I'm so much smarter or this is my con or something else to explain that but I doubt these lines of reasoning.
Best.
I do want what i wrote i want, but the program doesn't provide what i want though, that is my point.
Also, every new job I've had, I've watched my coworkers spend like a week trying to figure out how to make the IDE work with whatever environment, which then changes later... I just skip that.
> Also, every new job I've had, I've watched my coworkers spend like a week trying to figure out how to make the IDE work with whatever environment, which then changes later... I just skip that.
A single week to achieve better productivity? That's a sweet deal. It's about as much time as you need to figure out how the work email works, learn how to get to the cafeteria from your desk quickly, and so on. It's absurd to think that you'll be 100% productive that first week anyway, so why not use the opportunity to familiarize yourself with the tooling as well?
Past jobs had similar caveats. The only time I've ever been able to use a debugger consistently was in school.
But in all seriousness. Using a debugger can be useful, and even though I've given it a try numerous times, I mostly avoid it because it doesn't fit the way I think.
Debugging is about searching for the source of the problem. With print debugging I'm always leaving behind breadcrumbs which I can inspect all at once at the end. If I'm going down a wrong path I delete the wrong ones and add new ones until I find the issue.
With a debugger I have to mouse around, put breakpoints, run the code, inspect where I'm at, step through, decide that this breakpoint is useless, and have to have all this state in my mind. If I get lost, I have to start from scratch.
Print debugging matches my way of thinking much more.
Now, if they were larping as PC/Mac one... (or certain groups of Unix weenies)
but i also think 'plain' ol (now amazon) freertos is pretty cool still
I write a lot of pure Win32 C, and I don't even need a Makefile for the majority of my projects because they're just compiled as a single file and quickly enough that I don't bother with anything more than necessary.
IMHO the "tool fetish" that a lot of (mostly newer) programmers seem to have is an artifact of a mentality that favours complexity and novelty over simplicity and efficiency. They will waste tons of time and resources configuring and debugging (often with little understanding) huge complex monstrosities of "development environments", and end up feeling more productive, but in reality aren't.
This article just further confirms what I'd already expected with the word "modern".
I think simplicity is underrated too, but I hope you'll agree that your single c file use case is rather niche.
Imagine developing an embedded device for medical or aerospace hardware : you are going to provide lost of effort into testing. You are going to work with teams of people with varied abilities and experience : it's going to get a little bureaucratic, there are going to have rules and guidelines. Enforcing those with tools remove part of the friction, if done well.
Most avionics these days are done in Simulink, and then you hit the Autocode button.
If you don't have the exact machine any more, then it's "Good luck getting the toolchain and build environment from the vendor!"
Docker has saved my bacon at least twice in this manner.
For things where kernel changes matter, sure a VM may provide better isolation, but should you ever run into problems running your older Docker images, you can easily solve that by spinning up a VM to run Docker in as a worst case fallback.
Docker strikes a nice balance of ease of integration and sufficient isolation for most situations.
It can be a vm, even a chroot.
Also the compatibility questions and docker "opacity" come to mind.
A QEMU VM sounds like a better propositions
chroot sounds like nothing but a headache.
QEMU VM, I don't even understand the potential advantage of lol
People try with mocks and stubs, but hardware in the loop is the only way you can know your firmware works as expected on device.
Real developers only code in Assembly with ed.
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
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.
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.
Corporate insistence on providing ill-fitting developer hardware (Macs) to what our software was being developed on (Linux, and in fact only runnable there) is why they might have paid the cost of few more laptops just for my single EC2 used to have reasonable compile times.
And I wasn't even using the host filesystem for any of the busy path - it was just compile definitions and storage for built tarballs and images (if it had to schlep actual source files and temporary files over, I might have had to wait a week for a single build to finish...)
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.
- https://marketplace.visualstudio.com/items?itemName=ms-vscod...
- 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).
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".
It is entirely optional, yet extremely useful.
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.
I use mingsys though . But theoretically it should be no trouble to change the compiler.
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).
> 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.
Perhaps if you have a 20+ person team it's possible that a supplier charges "a cool mil", but I'm pretty skeptical. If you have a big team anything can be expensive. That would be like implying laptops cost $20k, because you bought for a whole department.
This shit is expensive, but not THAT expensive. Support is like a grand for lessons, $150-300/hr. However, these are very normal rates for any engineering labor.
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.
There's a bunch of problems that Docker solves for embedded toolchains that other C developers don't need to care about.
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.
* 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.
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.
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.
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/ 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.
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.
The correct thing to do, imho, is check-in toolchains to version control.
[0] https://docs.unrealengine.com/5.0/en-US/setting-up-turnkey-f...
In C/C++ land? Nix is the virtual env. It’s the only sane choice for that as a user land stack.
> 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.
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.
[1] https://wiki.alpinelinux.org/wiki/Running_glibc_programs
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)?
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.
[1] https://askubuntu.com/questions/92019/how-to-install-specifi...
apt rollback=2011-01-01
I think this is basically what Nix is?!
$ 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).
Make Zig Your C/C++ Build System
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-replace...
https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...
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.
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.
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."
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
I think you're either wildly exaggerating or you've been creating your own problems.
> 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()
> 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.
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)…
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.
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.
roots in boehm means globals and the stack. this little thing had explicitly declared roots.
edit: I found it, mail me at yuri@tenuki.org. be prepared to be unimpressed.
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.
Have my thanks.
1: https://docs.platformio.org/en/latest/platforms/creating_pla...
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.
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”
by your definition, is that any language less than 50 years old?
Apparently since the Morris worm (1988), it took a while to undestand what kind of features C was capable of.
nope. they all are. all depends on the use case. if your use case is "must do 100% of what C can do, no exceptions" then of course that leaves one option. but for many programmers the trade offs today are not in favor of C, and haven't been for some years.
If you need to target very tiny boards, none from that list are suitable C replacements, _maybe_ zig and D with betterC since they both provide an inline assembler
Otherwise we'll end up with companies using Raspberry Pi 4 for their fleet of scooters because "i can run nodejs on it" (hyperbole, but you get the idea) https://news.ycombinator.com/item?id=37016842
The smallest one was an ATTiny 13A (64 bytes of RAM).
> The smallest one was an ATTiny 13A (64 bytes of RAM).
It counts, but at that point (64bytes of RAM) there is no benefit to using Rust.
I don't see this as a place where Rust can't replace C (or where Zig is a better replacement, or whatever) because why are we writing any high level language at all?
I guess it can make sense if there's a device family and this is the smallest of a range.