5 ms·

I think the main issue is that most build systems are not expressive enough to do complex packaging, code gen, etc that most projects need. I've been using Baze

I think the main issue is that most build systems are not expressive enough to do complex packaging, code gen, etc that most projects need. I've been using Bazel for a few projects/teams and it's worked really well. Once your build system is as expressive as you need you get a lot of freedom. Bazel also let's you execute completely local builds and remote builds triggered locally. If you set this up debugging CI issues is amazingly simple.

octopoc 6y ago
Totally agree. I've never used Bazel; it sounds a lot like Nuke. I had a coworker whose job was to maintain the CI. His commit messages would look like this sometimes: > Fix CI issue with blah blah blah > Hmm that didn't work lets try something from stackoverflow > Build fix > Build fix please work > Please > I hate my life > I am tired and hungry, I want to go home > Stupid yaml The CTO would call him like a week later to make sure he was okay. This happened often before we switched to Nuke. It rarely happened afterwards. It's awesome being able to debug your CI locally.
- gravypod 6y ago
  Yep, and if you get everything working smoothly enough developers can use the same very polished tooling for their own workflow.
- nly 6y ago
  The problem in C++ land (my land) is all your dependencies are probably using different build systems. Do you wan to migrate all your third party libs to Bazel, or just hack up a few lines of CI yaml to call the authors build system? I lean on gitlab yaml quite heavily and it feels quite effortless
  - vsgzusnex 6y ago
    We vendored all of our third party dependencies into our Bazel build. There were a lot and it was a giant PITA but over a multi-year horizon it was worth it. That doesn't mean it's the right choice for every business but it paid off for us.
    - nly 6y ago
      Vendoring all your third party dependencies is fine, but you still have to build them. Personally I use the native build system that upstream uses for most of them, and just hack in my compiler flags/options where necessary. Then I use CI triggers to rebuild my projects when the dependencies are rebuilt.

octopoc 6y ago

Totally agree. I've never used Bazel; it sounds a lot like Nuke. I had a coworker whose job was to maintain the CI. His commit messages would look like this sometimes: > Fix CI issue with blah blah blah > Hmm that didn't work lets try something from stackoverflow > Build fix > Build fix please work > Please > I hate my life > I am tired and hungry, I want to go home > Stupid yaml The CTO would call him like a week later to make sure he was okay. This happened often before we switched to Nuke. It rarely happened afterwards. It's awesome being able to debug your CI locally.

gravypod 6y ago
Yep, and if you get everything working smoothly enough developers can use the same very polished tooling for their own workflow.
nly 6y ago
The problem in C++ land (my land) is all your dependencies are probably using different build systems. Do you wan to migrate all your third party libs to Bazel, or just hack up a few lines of CI yaml to call the authors build system? I lean on gitlab yaml quite heavily and it feels quite effortless
- vsgzusnex 6y ago
  We vendored all of our third party dependencies into our Bazel build. There were a lot and it was a giant PITA but over a multi-year horizon it was worth it. That doesn't mean it's the right choice for every business but it paid off for us.
  - nly 6y ago
    Vendoring all your third party dependencies is fine, but you still have to build them. Personally I use the native build system that upstream uses for most of them, and just hack in my compiler flags/options where necessary. Then I use CI triggers to rebuild my projects when the dependencies are rebuilt.