undefined

points

[-]

The problem is doing this requires a team to support it that is realistically as large as your average product team. I know Bazel is the solution here but as someone who has used C++, modified build systems and maintained CI for teams for years, I have never gotten it to work for anything more than a toy project.

by mgaunard1 hours ago|

parent|

[-]

I have several times built my own system to do just that when it wasn't even my main job. Doesn't take more than a couple of days.

Bazel is certainly not the solution; it's arguably closer to being the problem. The worst build system I have ever seen was Bazel-based.

by stackghost2 hours ago|

prev|

[-]

>Build everything from source within a single unified workspace, cache whatever artifacts were already built with content-addressable storage so that you don't need to build them again.

Which tool do you use for content-addressable storage in your builds?

>You should also avoid libraries, as they reduce granularity and needlessly complexify the logic.

This isn't always feasible though.

What's the best practice when one cannot avoid a library?

by mgaunard1 hours ago|

parent|

[-]

You can use S3 or equivalent; a normal filesystem (networked or not) also works well.

You hash all the inputs that go into building foo.cpp, and then that gives you /objs/<hash>.o. If it exists, you use it; if not, you build it first. Then if any other .cpp file ever includes foo.hpp (directly or indirectly), you mark that it needs to link /objs/<hash>.o.

You expand the link requirements transitively, and you have a build system. 200 lines of code. Your code is self-describing and you never need to write any build logic again, and your build system is reliable, strictly builds only what it needs while sharing artifacts across the team, and never leads to ODR.