Hacker News Reader

Honestly, I have the opposite opinion. I really don't like it when there are custom bash build scripts. And you have to figure out how they work and what they do. And how to pass additional parameters etc.

If you use Maven for your project, then I expect that if I run `mvn clean install` then it will build the project.

I think that is the whole point of standard build tools: that you can switch projects easily, run the same command and get the same result, and not waste time learning custom scripts for each project.

This is a common problem for programmers in general, not just at build time. Occasionally you will run into a case where the framework you've chosen just doesn't fit. You can try to hammer your need into the framework in some horrific fashion or your can temporarily circumvent it for this one task. Which path you go depends on a lot of factors.

I think FAKE (https://fake.build/), hits an amazing sweet spot for this: standardized, predictable, with no sacrifice of programming/platform power when dealing with builds.

Project to another, just run "build.fsx" with the desired target -- it will self-download necessary tools and packages -- and you'll get a straightforward standard build. If you want to see the logic, just open it up: build scripts are standard F# scripts

Because you're using first-class scripting you get full language power, full component and package management power, full abstraction power, aided by a set of utility methods and tools. At any point things get hairy you can wrap them into a lib, or a full program, with no domain impedance. It's standard code, as learnable as the rest of the F# proj, no voodoo, no black boxes.

Heck, you can also load your project and use its libraries during the build. I find myself often using FAKE components in my main solutions to take advantage of its interop and publishing...

> Now we simply have bash scripts that do all our one-offs that often were nightmares to accomplish in Gradle or Maven. Whether it is JAXB or Docker integration every maven/gradle plugin I ever used was 10 times harder than just bash.

This is the opposite of my experience. Trying to get consistent behaviour out of bash scripts is a nightmare (every nontrivial bash script has an undocumented dependency on a particular version of some system tool, every time you try to build on a new machine you're rolling the dice). Maven plugins are versioned and (usually) tested, have sane defaults, and will Just Work (provided you're willing to roll with their defaults rather than fighting it).

Funnily, 10 times harder is exactly my experience with most maven plugins. Maven is fine if you stick to compile, test, and jar. Anything beyond that just tends to escalate into madness.

> every time you try to build on a new machine you're rolling the dice

why not on copies of known-good machines? vm boxes with the same definitions would alleviate almost all of that 'roll the dice' aspect, no?

At that point you've frozen a working image of your dependencies along with a bunch of other stuff, but you still don't have a clear picture of what those dependencies are and how to work with them.

Your build works in a vm of RHEL 5 with packages x and y installed, ok, now you need to add a new build step that depends on something that's only available for RHEL 7. So you run the VM generate script (if you can even find it a year or two later) and the build doesn't work. Now you get the same fun debugging experience. Standardising which OS and package installs every developer uses (whether with a VM or just with something like Puppet) means you get to roll the dice less often, but it's still a dice roll whenever you want to change something.

And running all your builds in VMs has a cost in terms of performance but more importantly in terms of comprehensibility. If my build is just Maven I can run it in my IDE, then I can push one button differently and run it in my IDE with a debugger attached. If the build is running slowly and I'm not sure why, I can push one other button and now I'm running it with a profiler. Some of that is just an argument for having your build tooling written in the same language you're using for development (if I was working in e.g. Python, I'd be more likely to have a Python IDE and a Python profiler to hand, so would want to use a Python build tool), but even if you're used to working in Bash and C I'm not sure the VM advocates have good answers to how you debug something running in a VM as yet.

I do something similar but with a Makefile as the top level. Every project I work on has a top level default that will fetch dependencies and build the project.

Lower level recipes are either one liners that invoke a project specific builder (ex: mvn package) or they invoke a separate bash script.

For complicated polyglot projects it works great as each component can use its own native tooling yet the top level is consistent.

> Now we simply have bash scripts

Hm - I don't know about that. The biggest issue I found with Gradle was that it offered unlimited flexibility, and inevitably, somebody would mickey mouse sorcerer's apprentice the thing and stick something into the build script that didn't belong there. Although with enough effort you can do that in Maven, too, by the time you get to the point where you understand how to do that, you know better. I can't even imagine what sort of nightmares somebody with the even-more unlimited flexibility of a bash script could conjure up.