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?

@nim you can see the changes I'd like to have here:

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

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.

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 ?

@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.

@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

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.