←back to thread

Buck2: Our open source build system

(engineering.fb.com)
392 points mfiguiere | 1 comments | 06 Apr 23 16:05 UTC | HN request time: 0.412s | source
Show context
phendrenad2 ◴[06 Apr 23 21:48 UTC] No.35474996[source]▶
> Build systems stand between a programmer and running their code, so anything we can do to make the experience quicker or more productive directly impacts how effective a developer can be.

How about doing away with the build system entirely? Build systems seem like something that shouldn't exist. When I create a new C# .NET app in Visual Studio 2019, what "build system" does it use? You might have an academic answer, but that's beside the point. It doesn't matter. It just builds. Optimizing a build system feels like a lack of vision, and getting stuck in a local maxima where you think you're being more productive, but you're not seeing the bigger picture of what could be possible.

replies(14): >>35475210 #>>35475243 #>>35475249 #>>35475260 #>>35475271 #>>35475272 #>>35475320 #>>35475645 #>>35476535 #>>35476550 #>>35477035 #>>35480031 #>>35485001 #>>35487462 #
1. sebastos ◴[07 Apr 23 21:51 UTC] No.35487462[source]▶
For C++, the #include's kind-of-sort-of tell the story of what needs to be included in the build, and morally, it seems wrong that you should have to repeat that information anywhere. I recently watched a talk from cppcon from the people at tipi.build, which seemed to go along these lines. They've tried to completely tear away the entire notion that you should be writing separated build files that re-describe what you are already telling the compiler with your #include's.