4 ms·

I think for most projects, contributions are hard enough to come by without having to factor in a new build system. Honestly even bazel isn't built with bazel.

I think for most projects, contributions are hard enough to come by without having to factor in a new build system. Honestly even bazel isn't built with bazel. (it can be, but they do that as a test) It's like rolling a whole new project into your existing ones... For no clear reason. Perhaps it's a learning experience, however there's no reason to hobble a project with it. Thankfully, I doubt most established projects would suddenly switch to a custom build system. Also there are plenty of auxiliary tools developed for build systems which are at best, difficult to reproduce. If one needs to improve a build system... Try a pull request?

ndh2 9y ago
Yeah, about that last sentence. Are you actually a contributor to an existing build system? CMake? Make? Bazel? Anything?
- maccard 9y ago
  I agree with the sentence. I've contributed to both cmake and gradle to fix very specific pain points that I've experienced. It's definitely been less work than writing an entire build system because I don't like how big and complex the existing systems are.
lucideer 9y ago
> having to factor in a new build system. > there's no reason to hobble a project with it. I think this underestimates the complexity and overhead of using and configuring some* existing build systems, and also overestimates the complexity of running (no need to edit the build config for most contributions to the project, provided the build system works well) a custom build system. Established build systems are often complex due to being heavily generalised and configurable. I've seen projects with build configs that are longer and more complex than a custom build system for that project could be. > there are plenty of auxiliary tools developed for build systems This is the key comment. You can create your own custom build system while using lower level build-related libraries. There's no need to reinvent the wheel entirely. * I said "some" existing build systems: I'm sure some are simpler than others, so this may not apply universally.

ndh2 9y ago

Yeah, about that last sentence. Are you actually a contributor to an existing build system? CMake? Make? Bazel? Anything?

maccard 9y ago
I agree with the sentence. I've contributed to both cmake and gradle to fix very specific pain points that I've experienced. It's definitely been less work than writing an entire build system because I don't like how big and complex the existing systems are.

lucideer 9y ago

> having to factor in a new build system. > there's no reason to hobble a project with it. I think this underestimates the complexity and overhead of using and configuring some* existing build systems, and also overestimates the complexity of running (no need to edit the build config for most contributions to the project, provided the build system works well) a custom build system. Established build systems are often complex due to being heavily generalised and configurable. I've seen projects with build configs that are longer and more complex than a custom build system for that project could be. > there are plenty of auxiliary tools developed for build systems This is the key comment. You can create your own custom build system while using lower level build-related libraries. There's no need to reinvent the wheel entirely. * I said "some" existing build systems: I'm sure some are simpler than others, so this may not apply universally.