A different approach to building C++ projects(rachelbythebay.com) |
A different approach to building C++ projects(rachelbythebay.com) |
I find that the real problem is no one wants to properly learn how their build system works. I don't care if it's make, cmake or bazel -- whatever it is, you need to _learn_ it. I've worked with folks that have 20 years of experience, fantastic C/C++ developers, that look at a makefile and say "Ugh what is this complicated mess, can you do it in cmake or bazel or something" and expect a silver-bullet where-in the makefile build will somehow transform itself into a self-describing intuitive build system by virtue of some sort of hype-osmosis.
This is so true, it happened to me more than once.
A couple of projects ago, we had a complicated build process (7-8 manual build steps that depend on files generated from each other before) for an embedded system. I wrote a little makefile deleting all those 7-8 shell scripts and i was asked to re do it in cmake.. I was like wtf.. each clearly defined step in makefile would turn into multiple unreadable function calls in cmake.. why would anyone want to do that..
Not that Makefiles are perfect, but sometimes, the right tool for the job isn't the shiniest. Make does a job of being "good enough" for a lot of little tasks.
If this sounds like you, do yourself a favor and go through these slides (or watch the talk they came from):
https://github.com/boostcon/cppnow_presentations_2017/blob/m...
It really clarified things for me, but also avoids going too much into detail. You will definitely need more info as you go along, but you can look those things up in the docs. This presentation does a good job at showing the core essentials that you can build your knowledge on later.
The problem in my experience is you invest time learning build system A, then a year later build system B comes out, and not only do you need to relearn a bunch of stuff again, often build system B does some of the stuff of system A but not all of it, plus it does new stuff that you've never encountered before. Then this cycle repeats, endlessly, and every new team you join has adopted the newest build system.
Granted some ecosystems are worse than others here. in the JavaScript world it went something like: make/grunt/bower, gulp/webpack, esbuild, parcel, vite, rollup, and on and on it goes.
Even in the conservative Java ecosystem we've been through maven, ant, groovy/gradle...
Most of these tools offer incremental improvements for a huge learning cost. It's a nightmare.
I end up "Randomly" stabbing at things until it works just well enough to get that particular thing done then dropping it all because it was such a painful experience.
Compared to something like cargo which works really well, C++ and it's build tools just feel flaky.
It may be that I'm just missing a mental model to get to grips with it, but no other major programming language is like that from my experience.
Looking for something that is still alive in 2023
Looking for something that is still alive in 2023
Theon Greyjoy in "Game of Thrones" exhibited this condition.
It is a thing to overcome.
What on earth.
#pragma comment(lib, "xxx.lib")
I have found myself wishing that GCC would also get something like this.
function I2C_GetNumChannels(out numChannels: Longword): FT_Result; stdcall; external 'libmpsse.dll';
cc main.c -o blaI suspected that someone might have done it before, but didn’t know of any implementation. I’ll take a closer look at Visual C++ (used it in the last millennium for work) before deciding how mine should work.
FD: CMake developer
Of course, the other alternative is to simply #include _every_ file in your project into a single source file, then compile that. It’ll probably be faster than anything else you do, and eliminates several other foot–guns as well. And it means that your build script can just be a shell script with a single line that runs the compiler on that one file.
But these days I greatly prefer Rust, where building is always just “cargo build”. Doesn’t get much easier than that.
> Of course, the other alternative is to simply #include _every_ file in your project into a single source file, then compile that.
Yeah, no... recompiling the entire project whenever any file is touched is way too slow for any non-trivial project.
I'm not sure why C and C++ have such a bad story here. Some combination of greater intrinsic complexity (separate headers, underspecified source-object relationships, architecture dependency, zillions of build flags, etc), a longer history of idiosyncratic libraries which people still need to use, the oppressive presence of distro package managers, and C programmers just being gluttons for punishment, probably.
Not always the case; I have a project with
default.o: default.yaml
$(LD) -r -b binary -o default.o default.yaml
extern const char _binary_default_yaml_start[];
extern const char _binary_default_yaml_end[];
#define PARAM_YAML _binary_default_yaml_start
#define PARAM_YAML_LEN (_binary_default_yaml_end - _binary_default_yaml_start)
fwrite(PARAM_YAML, 1, PARAM_YAML_LEN, stdout);
Your use case would be served by C23's #embed [1]. The same thing has been proposed for C++ but repeatedly kicked down the road because the standardisation committee wanted to make it more general even though no one had any demand for that so they didn't know what it would look like. (C++ standardisation in a nutshell.)
> “If you want something like this to work, you have to commit to a certain amount of consistency in your code base. You might have to throw out a few really nasty hacks that you've done in the past. It's entirely likely that most people are fully unwilling or unable to do this, and so they will continue to suffer. That's on them.”
That goes for almost everything, in developing ship code.
Today, I am in the initial stages of rewriting an app with a codebase that has “accreted” over two years.
It’s kind of a mess (my mess, to be clear).
I’ll be adding a great deal of rigor to the new code.
I think it will come out great, but I have my work cut out for me.
Conan has a learning curve, but it’s totally worth it. Anyone making their own build system should get some experience with a state of the art package manager before writing a single line of code, because chances are that it already solves whatever problem is motivating you.
nix flake new --template "github:nixvital/flake-templates#cpp-starter-kit" my-project
will create a skeleton for my new C++ projects.
Conan obviously has promise, I haven't spent much time with it, most of my experience with C++ package managers is with nuget and vcpkg. However, my attitude toward package managers is changing.
I increasingly like _not_ using package managers because it makes me (and my company) way way way less likely to bloat our software with unnecessary third party dependencies.
I wrote this in another thread: I never believed you should write something yourself if you can find a package for it. My boss told me I should write it all myself, I could probably write it to be faster. I encountered a case where I needed to compare version numbers in python. For the heck of it I wrote the simplest, quickest, most naive solution I could come up with and then timed it against the most recommended version comparison package in python. I blew it away by 20x throughput.
I don't believe in package managers anymore. Obviously I'll keep using pip and sqlalchemy in Python, but I'll happily spend the 20-30 minutes it takes adding something like nlohmann-json or md4c to my project over worrying about maintaining a package manager for c++ these days. Precisely because it makes me think twice about adding another dependency.
And yaml parsing is probably on the simpler side of things. We need to run torch models, we do need libtorch. We are not rewriting libtorch, that would be silly.
Huge learning cost and even more huge interoperability cost. "Oh you need to cross compile your C++ project to that architecture? this dependency uses that build system and you need to build those libraries separately and make sure your build system can use that then"
For 90% of use-cases nothing beats the simplicity of Maven.
Just like in the last 2-3 years, every single new team I've joined is using kubernetes from day 1. Cargo culting is a huge force.
With large complex programs using complex incremental build systems, especially programs written in C++, you often end up spending most of your time processing the same header files over and over again. Some compilers use complex systems of pre–compiled headers that can paper over this cost, but building your whole program in a single compilation unit that only ever includes each file once eliminates it entirely without adding any additional complexity. If you want proof of this, go look at the efforts over the last year or two to shave a few minutes off the build time of the Linux kernel by carefully adjusting all of the header files, splitting them all into even smaller files so that each #include can bring in just what is needed. This avoids burdening the compiler with parsing things you aren’t going to use just to pull in a struct definition or two.
Plus, by having a single compilation unit you avoid the need to link a bunch of small object files together. Linking is the final step of building an executable, and it cannot generally be parallelized much. By reducing the amount of work the linker needs to do you can greatly speed up a step that can’t be sped up any other way.
But the real reason I recommend it is its simplicity. By spending less programmer time on the build system you can significantly reduce the overall development cost of the whole program. This is a huge benefit of Rust (and a lot of other modern programming systems) that is often overlooked. With a complex C++ program I might spend 10% of my overall development time monkeying around with the build system. If I write it in Rust I can avoid all of that; cargo can do everything I need while requiring only a very small amount of time configuring it. 10% of a project that takes a year is over a month, and with cargo that time expenditure is reduced to minutes or hours.
On the other hand, I have worked as a contractor for many years helping companies develop complex systems. It’s only a rough estimate, but I believe that I have earned over a hundred thousand dollars just by helping them with their complex build systems. A few days here, a few days there, it really adds up.
For a brief moment they almost had it with .NET Native and C++/CX, and then, first they killed C++/CX in name of C++/WinRT (with VS tooling just like in the good old ATL days), and with UWP's deprecation, CsWinRT also fails quite short of the .NET Native experience in regards to COM.
How a OS development team that is so invested into COM APIs, fails to produce tooling better than the competition for 25 years escapes me.
I've been in the industry for 30 years just in Canada. Have come to conclusion that software developers in their majority rarely prefer most efficient, elegant (whatever that means) ways of accomplishing things. I have a theory that being "software developer" is sort of self servant. Because of that they enjoy unneeded complexity, tooling etc. etc.
I personally have never indulged into coding for the sake of it. To me software development was always just a tool to build amazing products people / businesses would use. So I always think about product, how it will be used and how to get there with the least financial "damage" either for my own company or for a client.
I bet the announced Chrome efforts will again, require another adaptation.
Utter nonsense. For most projects CMake is far more readable and maintainable than Makefiles. There's a reason it's the only build system even close to being a de facto standard in the C++ world.
And yes, CMake is totally awful. But it's still slightly better than Make.
(Feel free to post the Makefile!)
That's only true for pure C/C++ projects. (I haven't used cmake with other languages so i won't comment on that.). I was specifically talking about the project where there were 7-8 shell scripts to build each intermediate step's target.
When you have to call external commands to build your artifacts, you end up relying on:
add_custom_target()/add_custom_command()/execute_process()/etc..
Example from that Makefile:
$(DISK_IMAGE): $(PARTITION_LAYOUT) $(BOOT_IMAGE) $(SYSTEM_IMAGE) $(HOME_IMAGE)
$(info "~~~~~ Creating disk image ~~~~~")
$(eval PARTITION_LAYOUT_BOOT_START:=$(shell grep boot $(PARTITION_LAYOUT) | grep -oP 'start=\s*\K(\d+)'))
$(eval PARTITION_LAYOUT_SYSTEM_START:=$(shell grep root $(PARTITION_LAYOUT) | grep -oP 'start=\s*\K(\d+)'))
$(eval PARTITION_LAYOUT_HOME_START:=$(shell grep home $(PARTITION_LAYOUT) | grep -oP 'start=\s\*\K(\d+)'))
dd status=none if=/dev/zero of=$(DISK_IMAGE) bs=1M count=2000
sfdisk $(DISK_IMAGE) < $(PARTITION_LAYOUT)
dd conv=notrunc if=$(BOOT_IMAGE) of=$(DISK_IMAGE) bs=$(BLOCK_SIZE) seek=$(PARTITION_LAYOUT_BOOT_START)
dd conv=notrunc if=$(SYSTEM_IMAGE) of=$(DISK_IMAGE) bs=$(BLOCK_SIZE) seek=$(PARTITION_LAYOUT_SYSTEM_START)
dd conv=notrunc if=$(HOME_IMAGE) of=$(DISK_IMAGE) bs=$(BLOCK_SIZE) seek=$(PARTITION_LAYOUT_HOME_START)
Ah I assumed this was primarily a C++ project given the context of the discussion. You're right it's not really the right tool if you're not doing a C++ project!
> Example from that Makefile
Honestly that looks like a typical fragile Makefile. Grepping all over the place. Regexes. Shelling out to `dd`. This sort of build system leads to constant fighting confusing error messages. It's a "works for me" build system.
I can see one bug and it's only 10 lines!
I think you can use Makefiles robustly - if you only use it for handling the build DAG, but apparently the temptation to use it as a general scripting system is too great for basically everyone.
Makefile was the only tool that felt "good enough" compared to those shell scripts. As for "works for me" problems, i directly packed up my ubuntu 14.04 rootfs for chroot and told my colleagues this was / will be the only supported build environment for this task. (docker wasn't that widespread there back then).
> I think you can use Makefiles robustly - if you only use it for handling the build DAG, but apparently the temptation to use it as a general scripting system is too great for basically everyone.
This is very true. it starts off with "Oh i can just use bash eval for this simple math" and ends with "Okay this makefile is too ugly.. might as well use a python script to handle this step". I kinda wanted to write a make tool that integrated better scripting language then. and variable checking.
Error messages were typically manageable when you sprinkle enough :"|| (echo "Error: You didn't do the right thing; exit -1)"
* Drive everything with Cargo using `build.rs`. This sort of works but it's pretty horrible.
* Give up and just have your main build system run `cargo build`. This is what I normally do but again it's not ideal because it doesn't really integrate properly with your main build system.
* Give up on Cargo entirely. This is what Bazel does, and it's probably the most robust solution but it's still not ideal because most of the Rust ecosystem expects you to use Cargo (e.g. rust-analyzer).
I don't think any other languages have really solved this problem either but it is still an annoying problem.
As you say, this is not a problem with an ideal solution to draw upon. (languages are unavoidably different). From that perspective, I don't see any of these approaches as problems.
If your project is mostly Rust with a little something else sprinkled in, use build.rs ("horrible" is an exaggeration IMO, it's merely not ideal, again, because there exists no ideal).
If your project is mostly something-else with a little Rust sprinkled in, invoke `cargo build` from your build system, and again this is a perfectly adequate solution to a problem with no ideal solutions.
If your project is extra-special, invoke rustc directly, and that's a deliberately supported use case. Hell, I use rustc directly sometimes just because I can.
The bottom line is, Rust provides a best-in-class opinionated build system that is overwhelmingly used by the Rust ecosystem, with best-effort escape hatches for integrating into other projects. To say that Rust cannot "stand the idea that you might want to mix languages", as alleged by the person I originally replied to, is factually incorrect.