[go-rpm-macros] PR #23: macros: Accept options for %gotest

[Alexander Todorov]

atodorov opened a new pull-request against the project: `go-rpm-macros` that you are
following:
``
macros: Accept options for %gotest
``

To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/23

[Nicolas Mailhot]

nim commented on the pull-request: `macros: Accept options for %gotest` that you are
following:
``
I’m a bit wary of adding flags to such a low level macro: it sets an API in stone, that
will be quite hard to evolve later given how primitive and constraining the rpm options
parser is. Generic rpm macros controled via generic rpm variables are a lot easier to
handle long-term than low-level option parsing.

Your -tests rpm looks like a generic thing. I’d rather generate this subpackage in a
generic way than  expose a low-level non future proof API to packagers.

What exactly do you need  in `%build` `%install` and `%files` for `-tests` to exist? What
info does it need from the packager, and what can be autodetected from the upstream code
state?
``

To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/23

[Alexander Todorov]

atodorov commented on the pull-request: `macros: Accept options for %gotest` that you are
following:
``
@nim you can see the changes I'd like to have here:

https://github.com/osbuild/osbuild-composer/pull/282/files#diff-e9f97a745...

The backgroud is that the mentioned `osbuild-dnf-json-tests` binary should be converted to
use the syntax of the go testing module and be able to compile that and ship it into the
RPM. 

In `%build` I tried just `go test -c -o ...` but that caused rpmbuild to fail with missing
build-id. That's why I wanted to use the `%gotest` macro b/c it configures all flags
accordingly but then I bumped into the issue of the macro not supporting the options I
need.

As you can see I've got an easy workaround to defined another macro in my .spec file
and use that instead. But figured this could be something other folks want to do as well.
``

To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/23

[Nicolas Mailhot]

nim commented on the pull-request: `macros: Accept options for %gotest` that you are
following:
``
So what you really want, is better automation of the build stage, except the testing
module also requires you to use `go test` instead of `go build` as build command?

I suppose I could revisit the %build stage and add a variable somewhere to pass the lists
of things to build. And another for the lists of tests to build.

I don’t suppose, there is a magic inspection command that outputs the list of things that
can be built with go test -c ?
``

To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/23

[Alexander Todorov]

atodorov commented on the pull-request: `macros: Accept options for %gotest` that you are
following:
``
@nim I'm not sure what I actually need TBH. This whole area is rather new to me and
I'm trying to figure it out and make it work as I go along. Not necessarily in this
order.

From what `go help test` tells me I think it should support the same flags as `go build`
plus some more.
``

To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/23

[Nicolas Mailhot]

nim commented on the pull-request: `macros: Accept options for %gotest` that you are
following:
``
@atodorov It seems there are all too many of us in your case:(. Let’s try to figure it a
bit better before pushing changes that others will expect to be perfectly baked.

Right now, our build stage is under-automated, because
1. I could not figure a way to autodetect things that need building
2. I could not figure a way to safely name the result (your -o flag that plagues us every
time there is something to build)

1. can be “solved” by a variable listing the things to build
2. is a bit harder, because creating a list of target names won’t work with globs. I need
to figure an heuristic solid enough to work in most cases

Once those part are done  `go test -c` becomes just a trivial variant to implement
``

To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/23

[Lars Karlitski]

larsu commented on the pull-request: `macros: Accept options for %gotest` that you are
following:
``
I agree that we shouldn't add `-c` to this macro, because it's really meant to
execute test only. I've found a different solution for osbuild-composer, which uses
`go test -c` directly in the `%build` section.
``

To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/23

[Neal Gompa]

ngompa closed without merging a pull-request against the project: `go-rpm-macros` that
you
are following.

Closed pull-request:

``
macros: Accept options for %gotest
``

https://pagure.io/go-rpm-macros/pull-request/23