Go ports: cleanup, finish transition to USES=go started with r505321 (cat. sysutils-x11)

[dmgk]

Summary

Go ports: cleanup, finish transition to USES=go started with r505321 (cat. sysutils-x11)

• Remove custom build/install targets left in place after r505321
• Switch to the new GO_TARGET tuple syntax introduced in r512001

Test Plan

poudriere bulk -C: OK (113i, 120a)
exp-run

[tz]

Aloha Dmitri,

two short questions:

poudriere bulk -C -j120a: OK

Why only 12? Please always check both versions. Sometimes there are some side effects in building, nobody could foresee.

exp-run

Does this mean there was already an exp-run? If so please link the PR. In this case you can safely ignore my previous comment ;)

[dmgk]

In D21744#474762, @tz wrote:

Aloha Dmitri,

two short questions:

poudriere bulk -C -j120a: OK

Why only 12? Please always check both versions. Sometimes there are some side effects in building, nobody could foresee.

Hi Torsten,

Given that these ports are building fine now and there's no functional change to the software (no version updates etc) and only changes to the ports, I felt that it would be enough to test these patches only on a single FreeBSD version. I can run the same poudriere bulk builds on say 11.3 i386 and update test plan with results.

exp-run

Does this mean there was already an exp-run? If so please link the PR. In this case you can safely ignore my previous comment ;)

Not yet :) I was going to wait a day or two for the reviewers feedback before requesting an exp-run.

[tz]

In D21744#474777, @dmgk wrote:

In D21744#474762, @tz wrote:

Aloha Dmitri,

two short questions:

poudriere bulk -C -j120a: OK

Why only 12? Please always check both versions. Sometimes there are some side effects in building, nobody could foresee.

Hi Torsten,

Given that these ports are building fine now and there's no functional change to the software (no version updates etc) and only changes to the ports, I felt that it would be enough to test these patches only on a single FreeBSD version. I can run the same poudriere bulk builds on say 11.3 i386 and update test plan with results.

Ah, okay. Based on experience: most times everything is fine. And sometimes, especially if you don't expect anything, an dependency or something else will fail. Better be safe than to get fallout and helpful emails ;)

exp-run

Does this mean there was already an exp-run? If so please link the PR. In this case you can safely ignore my previous comment ;)

Not yet :) I was going to wait a day or two for the reviewers feedback before requesting an exp-run.

Please feel free to request it now. You can request all 3 reviews in one exp-run. :)

[tobik]

sysutils/consul-alerts/Makefile

13 ↗

(On Diff #62403)

USES=compiler no longer needed here.

sysutils/epazote/Makefile

13 ↗

(On Diff #62403)

USES=compiler not needed here.

sysutils/nomad/Makefile

17 ↗

(On Diff #62403)

USES=compiler no longer needed here.

www/minio-client/Makefile

33 ↗

(On Diff #62403)

MAKE_ENV is probably not needed here anymore.

[dmgk]

Remove leftover USES=compiler and MAKE_ENV.

[dmgk]

In D21744#474778, @tz wrote:

Ah, okay. Based on experience: most times everything is fine. And sometimes, especially if you don't expect anything, an dependency or something else will fail. Better be safe than to get fallout and helpful emails ;)

I've run poudriere bulk overnight on 113i and updated test plans with results.

Please feel free to request it now. You can request all 3 reviews in one exp-run. :)

Done, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240771

[araujo]

LGTM, same thing, wait for the exp-run and portmgr approval.

[dmgk]

Exp-run passed, can someone from portmgr please approve this and the other two patches: https://reviews.freebsd.org/D21743 and https://reviews.freebsd.org/D21741

[adamw]

I'll approve it.

I couldn't ever actually enforce this, but I'd like the approval to be on the condition that you follow it up by writing something for Mk/go.mk and porters-handbook on how to do Go-based ports correctly. There is essentially no documentation, and it's completely opaque for anybody looking to port go programs. This sweep is necessary because there's no direction on the "correct" way.

[dmgk]

In D21744#476942, @adamw wrote:

I'll approve it.

I couldn't ever actually enforce this, but I'd like the approval to be on the condition that you follow it up by writing something for Mk/go.mk and porters-handbook on how to do Go-based ports correctly. There is essentially no documentation, and it's completely opaque for anybody looking to port go programs. This sweep is necessary because there's no direction on the "correct" way.

Hi Adam,

Thanks. Some time ago @tobik wrote 6.5.8. Building Go Applications section that covers this process in details. It is tailored for Go modules, but I doubt that there will be much new Go software written that don't use them.

[adamw]

> Thanks. Some time ago @tobik wrote 6.5.8. Building Go Applications section that covers this process in details. It is tailored for Go modules, but I doubt that there will be much new Go software written that don't use them.

That's fair. However, this review is a sweeping change of all go ports to meet a specific, consistent standard, suggesting that the plurality of ports were doing things in a suboptimal way. IMO the PHB should demonstrate what the ports should and should not be doing.

[dmgk]

In D21744#476965, @adamw wrote:

That's fair. However, this review is a sweeping change of all go ports to meet a specific, consistent standard, suggesting that the plurality of ports were doing things in a suboptimal way. IMO the PHB should demonstrate what the ports should and should not be doing.

Makes sense. Perhaps it would be useful to have a list of "best practices" for creating Go ports. I'll extend the "Building Go Applications" section and post a doc review.

[araujo]

In D21744#477011, @dmgk wrote:

In D21744#476965, @adamw wrote:

That's fair. However, this review is a sweeping change of all go ports to meet a specific, consistent standard, suggesting that the plurality of ports were doing things in a suboptimal way. IMO the PHB should demonstrate what the ports should and should not be doing.

Makes sense. Perhaps it would be useful to have a list of "best practices" for creating Go ports. I'll extend the "Building Go Applications" section and post a doc review.

That would be fantastic, please do it! I'm doing a lot of Go projects at work and soon I will create ports for these projects, it would be handy have some additional documentation about the best practices.

Thank you.