DIR} ${GOROOT}/{} \; \
> > + -o -type f ! -name \*.orig \
> > + -exec ${INSTALL_DATA} -p {} ${GOROOT}/{} \;
> > +.endfor
>
> Indentation appears messed up here - it should be for.
Done.
Index: Makefile
==
On Sat, Apr 07, 2018 at 01:04:59AM +0200, Klemens Nanni wrote:
> Same thing as with lang/go: Simplify do-install, combine finds,
> fix space/tab mixtures.
>
> Feedback? OK?
Bump.
Index: Makefile
===
RCS file: /cvs/p
Same thing as with lang/go: Simplify do-install, combine finds,
fix space/tab mixtures.
Feedback? OK?
Index: Makefile
===
RCS file: /cvs/ports/lang/go-bootstrap/Makefile,v
retrieving revision 1.9
diff -u -p -r1.9 Makefile
hes that we currently have for lang/go-bootstrap have
> > been committed upstream - one of these is already in the go1.4
> > release tarball that is available, while some have been committed and
> >
> > will appear in the next tarball that's created:
> > https:
On 2017/10/09 03:34, Joel Sing wrote:
> Upstream is providing a tarball of the release-branch.go1.4 git branch,
> which contains minor fixes to keep Go 1.4 building on current platforms.
> Most of the patches that we currently have for lang/go-bootstrap have
> been committed up
Upstream is providing a tarball of the release-branch.go1.4 git branch,
which contains minor fixes to keep Go 1.4 building on current platforms.
Most of the patches that we currently have for lang/go-bootstrap have
been committed upstream - one of these is already in the go1.4
release tarball
On Wednesday 23 December 2015 03:02:25 Joel Sing wrote:
> On Wednesday 09 December 2015 00:40:28 Joel Sing wrote:
> > I'll rework go.port.mk and the relevant packages using /usr/local/go-pkg.
>
> This reworks go.port.mk to install packages in /usr/local/go-pkg and builds
> without -a, -work and
Joel Sing said:
> I don't want to patch /usr/local/go-pkg into the default $GOPATH - that would
> likely create a bunch of "oh, why is it behaving like that" problems. We
> could
> tell people to add it to their Go path if they want to use it, but I'm
> tempted
> to only use it for port build
On Wednesday 09 December 2015 00:40:28 Joel Sing wrote:
> I'll rework go.port.mk and the relevant packages using /usr/local/go-pkg.
This reworks go.port.mk to install packages in /usr/local/go-pkg and builds
without -a, -work and without running things through sed and piping to shell.
The
On Thursday 10 December 2015 17:50:20 Michael McConville wrote:
> Joel Sing wrote:
> > Thanks for clarlifying - we could still implement 'go get -d' as a way
> > of getting sources, but it would be more work than it is likely worth
> > (and there are also some issues surrounding which versions of
Joel Sing said:
> This reworks go.port.mk to install packages in /usr/local/go-pkg and builds
> without -a, -work and without running things through sed and piping to shell.
> The net/websocketd and textproc/go-xlsx should now be fixed (along with
> their dependencies) - I still need to take a
Joel Sing wrote:
> Thanks for clarlifying - we could still implement 'go get -d' as a way
> of getting sources, but it would be more work than it is likely worth
> (and there are also some issues surrounding which versions of the
> dependencies get fetched).
>
> I'll rework go.port.mk and the
On Monday 07 December 2015 23:31:34 Stuart Henderson wrote:
> On 2015/12/08 10:05, Joel Sing wrote:
> > On Monday 07 December 2015 14:18:52 Kent R. Spillner wrote:
> > > On Tue, Dec 08, 2015 at 02:29:03AM +1100, Joel Sing wrote:
> > > > This brings me to the next issue/topic - installing
On Sunday 06 December 2015 16:44:33 Stuart Henderson wrote:
> Slight problem with the go update, it breaks build of some ports using
> the go module:
>
> textproc/go-xlsx
> net/go-websocket
> devel/go-check-v1
> devel/go-tools
I obviously did not get to look carefully at r1.2 of go.port.mk -
On Tue, Dec 08, 2015 at 02:29:03AM +1100, Joel Sing wrote:
> This brings me to the next issue/topic - installing additional packages under
> /usr/local/go is probably a bad idea.
My recollection is that the other issues you mentioned were necessary in order
to make this work. So if everyone
Joel Sing said:
> I obviously did not get to look carefully at r1.2 of go.port.mk - there are a
> number of issues that should be resolved:
>
> - Running 'go install -x' and piping the results through sed and sh -v is
> crazy. Firstly, 'go install -x' will *run* those commands, then they're
On 2015/12/08 10:05, Joel Sing wrote:
> On Monday 07 December 2015 14:18:52 Kent R. Spillner wrote:
> > On Tue, Dec 08, 2015 at 02:29:03AM +1100, Joel Sing wrote:
> > > This brings me to the next issue/topic - installing additional packages
> > > under /usr/local/go is probably a bad idea.
> >
>
Slight problem with the go update, it breaks build of some ports using
the go module:
textproc/go-xlsx
net/go-websocket
devel/go-check-v1
devel/go-tools
Michael McConville wrote:
> Michael McConville wrote:
> > Stuart Henderson wrote:
> > > Slight problem with the go update, it breaks build of some ports using
> > > the go module:
> > >
> > > textproc/go-xlsx
> > > net/go-websocket
> > > devel/go-check-v1
> > > devel/go-tools
> >
> > I'm working
On 2015/12/06 13:50, Michael McConville wrote:
> Also, make update-plist isn't recognizing the rc script for me. It says:
>
> > make-plist: Bogus element outside of every prefix: /etc/rc.d/godoc
You need to re-add this manually, update-plist doesn't handle rc scripts.
> -@comment $OpenBSD:
Stuart Henderson wrote:
> Slight problem with the go update, it breaks build of some ports using
> the go module:
>
> textproc/go-xlsx
> net/go-websocket
> devel/go-check-v1
> devel/go-tools
I'm working on an update for go-tools.
We have a manual install command for cover and vet, but the
Michael McConville wrote:
> Stuart Henderson wrote:
> > Slight problem with the go update, it breaks build of some ports using
> > the go module:
> >
> > textproc/go-xlsx
> > net/go-websocket
> > devel/go-check-v1
> > devel/go-tools
>
> I'm working on an update for go-tools.
>
> We have a
in Go, rather than C) - the
> > current "promise" is that the bootstrap will only use functionality
> > from the Go 1.4 API.
> >
> > So that we can continue to build natively, the attached is a
> > lang/go-bootstrap that is effectively the Go 1.4.3 release - this
>From Go 1.5 onwards, an existing go compiler is needed to bootstrap the build
(the runtime is now written in Go, rather than C) - the current "promise" is
that the bootstrap will only use functionality from the Go 1.4 API.
So that we can continue to build natively, the attached
Go 1.4 API.
>
> So that we can continue to build natively, the attached is a
> lang/go-bootstrap
> that is effectively the Go 1.4.3 release - this is intended purely for
> building
> Go 1.5+ and is not meant for installing/distributing otherwise (and it is
> marked as
25 matches
Mail list logo
