On 2020/10/07 16:28, Ricardo wrote:
> Hey Stuart,
>
> Damn, you are fast. abieber@ (thanks) just introduced me to portgen(1) and
> just before I finished reading the man page and you already attached a
> working port (from my brief tests, seems to be working fine on amd64).
>
> Why you say it's horrible? Besides fixing the man pages, how can I improve
> it?
I am referring to this:
do-build:
-cd ${WRKSRC} && ${MODGO_BUILD_CMD} ${ALL_TARGET}/cmd/...
cd ${WRKDIR}/go/pkg/mod/github.com/muesli/termenv@*; \
cp termenv_linux.go termenv_openbsd.go
cd ${WRKSRC} && ${MODGO_BUILD_CMD} ${ALL_TARGET}/cmd/...
The build process used by go.port.mk passes zips to go so it's
impossible to patch files inside them (or, as was needed in this case,
copy a file under a different name so it's found on OpenBSD) before
starting the build.
So what this is doing is "build it once and tell make to ignore
failures because we know it's going to fail", then fix up the thing
causing build to fail, then re-run the build.
Now...for gh there was a new version released yesterday, which uses
a newer version of the library that had this build problem, so this
can be avoided again, I'll send an update later.
But what is really needed is for the zips to be unpacked in the "make
extract" stage so they can be correctly patched by the ports
infrastructure, same as other ports do - of course this is normal
for C code distributed as tarballs - but even for more complex things
like rust+cargo, the port module does this the right way. Go to one
of the rust ports we have and "make patch", it extracts/patches the
files, "cd `make show=WRKSRC`" works, takes you to a directory
containing readable extracted files, they can be modified, "make
update-patches" works, etc.
Try to do this for go ports and the best you can do is run "make" and
hit ^C at the right point to get to a similar stage where you can
get at the files (and the ports "patch" infrastructure doesn't work
with them).
To fix this, go.port.mk will either need to replicate some of what go is
doing itself in its own build process, or if there's a way to tell go to
extract the zips as a preliminary stage without trying to build them,
that would also do the trick.
The current situation is that either we have to bodge it like in my
gh cli 1.0.0 Makefile, or that patches need to be committed to
released versions upstream (and maybe the software depending on those
libraries gets updated to use that updated version) before we're able
to use them in ports.
This is not really acceptable as sometimes we might need to patch
something urgently due to an important/security fix and we can't really
be forced to wait for upstreams to do something if this happens.
