> There are a lot of problems, but having to carefully construct the build environment is a minor one time hassle.

I've observed the existence in larger projects of "build engineers" whose sole job is to keep the project building on a regular cadence. These jobs predominantly seem to exist in C++ land.

▲ TuxSH 5 days ago | parent | next [-]

> These jobs predominantly seem to exist in C++ land.

You wish.

These jobs exist for companies with large monorepos in other languages too and/or when you have many projects.

Plenty of stuff to handle in big companies (directory ownership, Jenkins setup, in-company dependency management and release versioning, developer experience in genernal, etc.)

▲ josefx 5 days ago | parent | prev | next [-]

Most of what I have seen came from technical debt aquired over decades. With some of the build engineers hired to "manage" that themselves not being treated as programmers and just adding on top of the mess with "fixes" that are never reviewed or even checked in. Had a fun time once after we reinstalled the build server and found out that the last build engineer created a local folder to store various dependencies instead of of using vcpkg to fetch everything as we had mandated for several years by then.

▲ pjmlp 5 days ago | parent | prev | next [-]

I have been "build engineer" across many projects, regardless of the set of programming languages being used, this is not specific to C++.

▲ jandrewrogers 5 days ago | parent | prev | next [-]

I’ve only ever seen this on extraordinarily complex codebases that mixed several languages. Pure C++ scales really well these days.

▲ wojciii 5 days ago | parent | prev [-]

How is that even possible?

Wasn't CI invented to solve just this problem?

▲ vlovich123 5 days ago | parent [-]

You have a team of 20 engineers on a project you want to maintain velocity on. With that many coooks, you have patches on top of patches of your build system where everyone does the bare minimum to meet the near term task only and it devolves into a mess no one wants to touch over enough time.

Your choice: do you have the most senior engineers spend time sporadically maintaining the build system, perhaps declaring fires to try to pay off tech debt, or hire someone full time, perhaps cheaper and with better expertise, dedicated to the task instead?

CI is an orthogonal problem but that too requires maintenance - do you maintain it ad-hoc or make it the official responsibility for someone to keep maintained and flexible for the team’s needs?

I think you think I’m saying the task is keeping the build green whereas I’m saying someone has to keep the system that’s keeping the build green going and functional.

▲ AdieuToLogic 5 days ago | parent | next [-]

> You have a team of 20 engineers on a project you want to maintain velocity on. With that many coooks, you have patches on top of patches of your build system ...

The scenario you are describing does not make sense for the commonly accepted industry definition of "build system." It would make sense if, instead, the description was "application", "product", or "system."

Many software engineers use and interpret the phrase "build system" to be something akin to make[0] or similar solution used to produce executable artifacts from source code assets.

0 - https://man.freebsd.org/cgi/man.cgi?query=make&apropos=0&sek...

▲ vlovich123 5 days ago | parent [-]

I can only relate to you what I’ve observed. Engineers were hired to rewrite the Make-based system into Bazel and maintain it for single executable distributed to the edge. I’ve also observed this for embedded applications and other stuff.

I’m not sure why you’re dismissing it as something else without knowing any of the details or presuming I don’t know what I’m talking about.

	▲	AdieuToLogic 3 days ago \| parent [-]
		>>> You have a team of 20 engineers on a project you want to maintain velocity on. With that many coooks, you have patches on top of patches of your build system ... >> The scenario you are describing does not make sense for the commonly accepted industry definition of "build system." > I’m not sure why you’re dismissing it as something else without knowing any of the details or presuming I don’t know what I’m talking about. My apologies for what I wrote giving the impression of being dismissive or implying an assessment of your knowledge. This was not my intent and instead was my expression of incredulity for a build definition requiring 20 engineers to maintain. Perhaps I misinterpreted the "cooks" responsible for build definition maintenance as being all of those 20 engineers. If so, I hope you can see how someone not involved in your project could reach this conclusion based on the quote above. Still and all, if this[0] is the Bazel build tool you reference and its use is such that: `With that many coooks[sic], you have patches on top of patches of your build system where everyone does the bare minimum to meet the near term task only and it devolves into a mess no one wants to touch over enough time.` Then the questions I would ask of the project members/stakeholders are: `1 - Does using Bazel reduce build definition maintenance verses other build tools such as Make/CMake/etc.? 2 - Does the engineering team value reproducible build definitions as much as production and test source artifacts? 3 - If not, why not?` EDIT: To clarify the rationale behind questions #2 and #3: Build definitions are production code, because if the system cannot be built, then it cannot be released. Test suites are production code, because if tests fail, then the build should fail and the system cannot be released. 0 - https://bazel.build/start/cpp

▲ wojciii 2 days ago | parent | prev [-]

I worked in companies that did this .. 20 years ago. I didn't imagine that this was still possible.

For me it's just about rules/discipline: Commit working code with passing unottests. Everyone is responsible for fixing stuff. You break something you'll fix it.