Don't want to use golang { build { ... } } How to configure tasks?

[ghost]

Hi. I don't want to use the default tasks for far too many reasons to list them all here. How do I configure tasks s.a. Build to use required parameters, for instance, GOPATH and the package it needs to build?

Ideally, this would be something like:

task buildSomething(type: Build) {
    gopath = "/somewhere/someday:/elsewhere/in/vendor"
    package = "package/to/build"
    executable = "executable-to-create"
}

[blaubaer]

It should work with the same configuration for every task like for the root configuration.

Example:

task buildSomething(type: Build) {
    golang {
        platforms = 'linux-386,linux-amd64,windows-386,windows-amd64,darwin-amd64'
        packageName = 'package/to/build'
        build {
            gopath = '/somewhere/someday:/elsewhere/in/vendor'
            outputFilenamePattern = 'executable-to-create-%{platform}%{extension}'
        }
    }
}

If you do not want to use the life cycle I current defined - what kind of life cycle do you prefer? I'am open for good new input. :smiley:

[ghost]

Well, I don't want the "toolchain" part because I don't want anyone to have to install Go via build script (that's the decision the developer needs to make, not the build system). I want to use go list to find the dependencies. I don't really understand how your plugin finds the dependencies. I have to admit I don't really know how Gradle treats tasks inside tasks, if I have two tasks "buildSomething" and "buildSomethingElse" both with "golang" task inside - wouldn't it cause a naming conflict? Finally, how do I override upToDateWhen and similar for such tasks? I think my biggest struggle is with absence of documentation, debugging tools and sources on Gradle part, so I don't want any complex code that I don't know the purpose and function of.

[blaubaer]

Well, I don't want the "toolchain" part because I don't want anyone to have to install Go via build script (that's the decision the developer needs to make, not the build system).

The toolchain task is required to ensure the whole setup of the toolchain. I guess to want to address that you want to use your own (local installed) GO version, right? If so I can add a property that will make this possible.

I want to use go list to find the dependencies. I don't really understand how your plugin finds the dependencies.

It is not required for you to understand how my plugin finds all dependencies. But for you is important to know that:

1. The plugin can pin versions of dependencies or can download specific revision numbers from a Git repo.
2. Let handle the plugin the dependencies. Do not do this by your own. It will download dependencies, place it at the right positions, ... If the current behavior does not fit your needs, tell me how to fit it... but not with: I want to do this by my self - in this case you do not need my plugin
3. The plugin cannot use go list do dive deep into every dependency also in other versions.

I have to admit I don't really know how Gradle treats tasks inside tasks, if I have two tasks "buildSomething" and "buildSomethingElse" both with "golang" task inside - wouldn't it cause a naming conflict?

No. Because golang is not a task, it is a configuration object inside a task or global scope. The task scope is more important than the global scope.

Finally, how do I override upToDateWhen and similar for such tasks?

This is not sooo easy. I'am currently also on this topic. Like you I don't want to compile everything every time. But in Gradle this is sometimes a little bit too generic. :smile: Please tell me your ideas on what it will be the best points to check for upToDate.

I think my biggest struggle is with absence of documentation, debugging tools and sources on Gradle part, so I don't want any complex code that I don't know the purpose and function of.

You are right. I have definitely to improve the documentation. But this plugin is at the beginning of the development process with sometimes big changes. In the future I will add more useful stuff here. And you are also right: Don't care too much of Gradle. Gradle is an extreme generic kind of software and in this case sometimes a mass. I want to keep the configuration simple as possible and also the knowledge of Gradle it self and Golang.

At the end of the day I'am always interested in examples what guys want to solve. In this case I can inspect and adapt.

Thank for your support.

[blaubaer]

Closed this because got no new input since the last months.