Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A different approach to building C++ projects

rachelbythebay.com

Post reply on HN
Print view View original

51–60 of 74 posts

Re: A different approach to building C++ projects

#51

Post by saidinesh5 »

IshKebab wrote: post #47
saidinesh5 wrote: post #36

Earlier quoted context omitted.

> I've worked with folks that have 20 years of experience that look at a makefile and say "Ugh what is this complicated mess, can you do it in cmake or bazel or something" 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 deletin…

> each clearly defined step in makefile would turn into multiple unreadable function calls in cmake 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!)

> For most projects CMake is far more readable and maintainable than Makefiles

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)
When you toss in other variables, cmake becomes a lot more verbose/less readable for these kind of use cases. Other steps in that Makefile were about generating, signing, verifying each of the partition images, fetching keys from the servers etc.. That whole Makefile was 500+ lines, and pretty sure in cmake it would have been lot longer.

Re: A different approach to building C++ projects

#52

Post by saidinesh5 »

davedx wrote: post #38
matthewaveryusa wrote: post #33

Earlier quoted context omitted.

This is wisdom right here. It's tragedy of the commons. 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 o…

> whatever it is, you need to _learn_ it. 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 h…

> Most of these tools offer incremental improvements for a huge learning cost. It's a nightmare.

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"

Re: A different approach to building C++ projects

#53

Post by db48x »

dezgeg wrote: post #49
db48x wrote: post #48

Has everyone forgotten about deps files? Run gcc -MD and it will create .d files that record the dependencies between your source (and header) files. You can then use an include directive in your Makefile to pull that information in for make to use. There are a couple of variations on the theme; some people recommend putting the .d files alongside your source files, others recommend a specific “deps” directory for th…

How does gcc -MD help at all in tracking which .cpp files to link in? > 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.

Most projects don’t have a lot of .cpp files that they don’t use :) You’re ultimately going to use them all.

Re: A different approach to building C++ projects

#54

Post by moloch-hai »

xnorswap wrote: post #24
Sakos wrote: post #3

This is sort of unrelated, but that reminds me that one of my biggest issues with learning C++ was how I was expected to deal with libraries (particularly on Linux, where conventions will even differ between distros) and building the project. Most guides or what have you sort of teach you how to compile a file or two, but you quickly run into issues that are difficult to solve for a complete beginner without a direct…

Every time I've tried to dabble in C++ I've had the same horrible experience. 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, bu…

In Behavioral Science this phenomenon is called "learned helplessness". The rabbit will not flee the cage even with the door propped open and no one around.

Theon Greyjoy in "Game of Thrones" exhibited this condition.

It is a thing to overcome.

Re: A different approach to building C++ projects

#55

Post by yonz »

xnorswap wrote: post #24
Sakos wrote: post #3

This is sort of unrelated, but that reminds me that one of my biggest issues with learning C++ was how I was expected to deal with libraries (particularly on Linux, where conventions will even differ between distros) and building the project. Most guides or what have you sort of teach you how to compile a file or two, but you quickly run into issues that are difficult to solve for a complete beginner without a direct…

Every time I've tried to dabble in C++ I've had the same horrible experience. 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, bu…

Same here and I'm dreading starting back up again. Are there any Gradle /npm like package managers that might simplify this?

Looking for something that is still alive in 2023

Re: A different approach to building C++ projects

#56

Post by yonz »

xnorswap wrote: post #24
Sakos wrote: post #3

This is sort of unrelated, but that reminds me that one of my biggest issues with learning C++ was how I was expected to deal with libraries (particularly on Linux, where conventions will even differ between distros) and building the project. Most guides or what have you sort of teach you how to compile a file or two, but you quickly run into issues that are difficult to solve for a complete beginner without a direct…

Every time I've tried to dabble in C++ I've had the same horrible experience. 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, bu…

Same here and I am dreading starting back up again. Are there any Gradle /npm like package managers that might simplify this?

Looking for something that is still alive in 2023

Re: A different approach to building C++ projects

#57

Post by dharmon »

matthewaveryusa wrote: post #33
boris wrote: post #13

I wish we had a culture that expected every new C/C++ build system to handle a non-trivial project like Boost or Qt (and their dependencies, like ICU and OpenSSL) before it being pitched as the new best thing. It's trivial to make a build system that elegantly handles your own toy projects that follow your preferred style and structure. But the real world of C/C++ is a harsh place with a lot of variability.

This is wisdom right here. It's tragedy of the commons. 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 o…

Like many C++ devs I hacked around in cmake for years, but not really understanding what I was doing or how to structure cmake projects. This was made worse as newer ways of doing things came into being.

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.

Re: A different approach to building C++ projects

#58

Post by klyrs »

db48x wrote: post #53
dezgeg wrote: post #49

Earlier quoted context omitted.

How does gcc -MD help at all in tracking which .cpp files to link in? > 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.

Most projects don’t have a lot of .cpp files that they don’t use :) You’re ultimately going to use them all.

Most people only change one or two files at a time. Those files, and the few that depend on them, must be rebuilt upon a change. Incremental builds only do what's necessary. Your proposal always builds everything no matter how trivial the change. It does not scale.

Re: A different approach to building C++ projects

#59

Post by breakds »

I have been managing all my existing and new projects with nix for a few years and never look back. Guaranteed to build and run on all my machines.

nix flake new --template "github:nixvital/flake-templates#cpp-starter-kit" my-project

will create a skeleton for my new C++ projects.

Re: A different approach to building C++ projects

#60

Post by klik99 »

bogwog wrote: post #17

Conan + (any build system) = problem solved 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.

Yes, this. I've been reading many comments here about problems with different dependencies and their own unique build system and kept thinking "Conan would fix that". I'm surprised that it's still so unknown in the C++ world.
Post reply on HN