Hacker News Reader

Comment by pandemic_region | Hacker News Reader

> bld was created because we're not really interested in build tools. We use them because we have to, but we'd rather just get on with coding the real stuff.

no interest in build tools, so let's create our own. Baffling.

View on HN

Never heard of bld before, but my read is that they were overwhelmed by the complexity of existing tools, and wanted one with minimal frills that doesn't get in the way and which looks like app code (as opposed to using a declarative language), so they wrote one. I suppose they wanted to "get it over with"... whether this is a pipe dream or not remains to be seen ;)

Build tools are complex because builds are complex. Of course, if you create a bespoke tool for your specific use case and then a bunch of other people use it but it doesn't really gain widespread adoption, you can keep stuff simple.

I'm not saying that there's not accidental complexity in current build tools and that a new build tool couldn't strike the balance better, but a rarely used build tool being simple doesn't really say much (and this much is true for almost any kind of software).

I'm not disputing anything you say, but my comment was aimed at explaining why someone who doesn't like dealing with build tools would want to write one.

I don't want to have to defend their choice or explain why build tools are often complex and cumbersome.

Sadly there's tons of code-based Java build tools, but possibly zero concise (toml/yaml- like) declarative build tools. If you're currently using Groovy or Kotlin scripts for building Java projects however, then Java build scripts are appealing.

I mostly like the Kotlin flavor of Gradle, but it still has some relatively simple workflows for which you need to deeply understand the execution model of Gradle. The ideal build tool would just work intuitively - i.e. would be geared towards developers rather than build tool nerds.

For example, I wanted a standalone database migration task that wouldn't be run by default. The magic for that is "doLast", which I don't think describes what it's actually doing particularly well.

    tasks.register("db-migrate", DatabaseSetup::class) {
        doLast {
            println("Now migrating")
            migrate()
            jooqGenerate()
        }
    }

The thing about gradle is that you need to understand its model first (especially that you're describing build steps, not executing them directly). After you do that, it's not that hard anymore, but I agree that it would be better if it was slightly more intuitive.

But then again, this is well explained in the docs, it's just that, sadly, today nobody has any time to read docs for the 5000 tools that we use anymore (which I can't fault individual engineers for).

His complaint is that it should have been something like "executeTask" or "doAction" or "lazyTask". Anything that implies something about the execution model of the task. Nobody really cares about the order of the actions within a single task most of the time.

In the example the DatabaseSetup is an existing task type that is registered under a new name. Since that has an action body, the doFirst and doLast append logic to run around that. Thus, after setting up the database it then runs a migration and code generator phase. The more straightforward way is to define a new task and use a dependsOn relationship.

    val databaseSetup = tasks.register<DatabaseSetup>("databaseSetup")
    tasks.register<GenerateJooq>("generateJooq") {
      dependsOn(databaseSetup)
    }

    class GenerateJooq : DefaultTask() {
      @TaskAction fun run() {
        println("Now migrating")
        migrate()
        jooqGenerate()
      }
    }

It is more code to define the custom task, but then allows for adding command-line input options. The doFirst / doLast are script shortcuts for quick proof-of-concept projects, whereas custom tasks are preferred for maintainability of long-lived ones.

Reply on news.ycombinator.com