[9fans] Building Go on Plan 9

[9fans] Building Go on Plan 9

[Anthony Martin]

[-- Attachment #1: Type: text/plain, Size: 188 bytes --]

A few people were asking about this so I
wrote up a tutorial.  I also uploaded a
copy to http://apm.sdf.org/go/NOTES for
anyone who has trouble with attachments.

Cheers,
  Anthony

[-- Attachment #2: NOTES --]
[-- Type: text/plain, Size: 3642 bytes --]

# Building Go on Plan 9
# Anthony Martin
# ality@pbrane.org


# This document will guide you through the process
# of compiling the commands and packages in the Go
# source code distribution.
#
# Before we get started you should make sure you
# have GNU Make installed.  The version on contrib
# is 3.81 and is just fine for our purposes.
#
# It's also necessary to have Mercurial installed
# and I believe there is a version on contrib as
# well.
#
# After reading this document you can extract the
# commands and pipe them to the shell using:
#
#     sed -n 's,^[% ] ,,p' NOTES | rc
#
# I highly recommend reading all the way through
# before running the commands.
#

# First we must fetch the archive that contains
# modified include files, a build script, and a
# patch consisting of all pending (and not yet
# submitted) CLs pertaining to Plan 9.

% cd /tmp
% hget http://apm.sdf.org/go/root.tbz >root.tbz

# Next we must verify the SHA1 hash of the archive.

% want = ed25980b3b813b1c80506b56331d83c4d485a4c0
% have = `{sha1sum root.tbz | awk '{print $1}'}
% if(! ~ $have $want){
    echo 'ZOMG! INVALID SHA1 CHECKSUM'
    echo have: $have
    echo want: $want
    exit badhash
  }

# Now we're ready to fetch the source code for the
# Go repository hosted at Google Code.  I had to
# make a decision about where this would reside so
# after a bit of thinking I chose /sys/src/go to
# mirror the structure of APE.
#
# The other important directories that will be
# created when extracting the archive are:
#
#   /386/bin/go     (for binaries),
#   /386/include/go (for machine dependent C headers),
#   /386/lib/go     (for Go's C libraries),
#   and
#   /sys/include/go (for machine independent C headers).

% cd /sys/src
% hg clone -u 2d7711ae https://go.googlecode.com/hg/ go
requesting all changes
adding changesets
adding manifests
adding file changes
added 10641 changesets with 40432 changes to 5437 files (+4 heads)
updating to branch default
3231 files updated, 0 files merged, 0 files removed, 0 files unresolved

# After fetching the Go repository we can extract
# the archive into the file system's root.  It's
# always a good idea to check the contents of an
# archive before doing something this drastic.

% cd /
% tar xvzf /tmp/root.tbz
tar: blocking = 16
386
386/bin
386/bin/go
386/include
386/include/go
386/include/go/ureg_x86.h
386/include/go/ureg_amd64.h
386/include/go/u.h
386/include/go/ureg_arm.h
386/lib
386/lib/go
sys
sys/include
sys/include/go
sys/include/go/bootexec.h
sys/include/go/mach.h
sys/include/go/ar.h
sys/include/go/bio.h
sys/include/go/stdio.h
sys/include/go/libc.h
sys/include/go/goenv.h
sys/src
sys/src/go
sys/src/go/9fix.patch
sys/src/go/src
sys/src/go/src/make.rc

# We're almost done.  We can now apply the patch file
# into the root of the Go tree.

% cd /sys/src/go
% ape/patch -p1 < 9fix.patch

# Our final step is to build the commands and packages.
# Running make.rc will produce tons of output so you
# might want to redirect it to a file.

% cd src
% ./make.rc

# Now that you have a working build of Go you
# should help me make sure all of the tests pass. :-)
# Email me if you're interested in helping out.
#
# In other news, I'm working on setting up an
# an automated builder so we can include Plan 9
# in the Go Dashboard.
#
# Also, please don't submit any of the changes in
# the patch file to the Go development list.  Most
# of the changes have corresponding CLs and the few
# others are still being pondered.
#
# That's all for now.  Have fun!

Re: [9fans] Building Go on Plan 9

[erik quanstrom]

please just post again inline because 9fans.net doesn't archive attachments.

- erik

Re: [9fans] Building Go on Plan 9

[John Floren]

On Thu, Dec 1, 2011 at 9:48 AM, Anthony Martin <ality@pbrane.org> wrote:
> A few people were asking about this so I
> wrote up a tutorial.  I also uploaded a
> copy to http://apm.sdf.org/go/NOTES for
> anyone who has trouble with attachments.
>
> Cheers,
>  Anthony
>

How many different Go porting efforts do we now have for Plan 9?
There's apparently yours, Ron's, Lucio's, and I think the 9front guys
have/had something cooking too.

Which ones can actually be updated with "hg pull"?


John

Re: [9fans] Building Go on Plan 9

[Stanley Lieber]

On Thu, Dec 1, 2011 at 12:00 PM, John Floren <john@jfloren.net> wrote:
> On Thu, Dec 1, 2011 at 9:48 AM, Anthony Martin <ality@pbrane.org> wrote:
>> A few people were asking about this so I
>> wrote up a tutorial.  I also uploaded a
>> copy to http://apm.sdf.org/go/NOTES for
>> anyone who has trouble with attachments.
>>
>> Cheers,
>>  Anthony
>>
>
> How many different Go porting efforts do we now have for Plan 9?
> There's apparently yours, Ron's, Lucio's, and I think the 9front guys
> have/had something cooking too.
>
> Which ones can actually be updated with "hg pull"?

Taruti has said the 9front port is dead, pending developments with the
other ports.

-sl

Re: [9fans] Building Go on Plan 9

[Anthony Martin]

John Floren <john@jfloren.net> once said:
> How many different Go porting efforts do we now
> have for Plan 9?  There's apparently yours, Ron's,
> Lucio's, and I think the 9front guys have/had
> something cooking too.

That's it as far as I know.

> Which ones can actually be updated with "hg pull"?

None yet.

I have CLs at the ready for every change
I've made and I'm committed to getting
them upstream.

Not to be presumptuous but I really think
the way I've done it is the best way forward.
All you need is GNU Make, Mercurial, a few
modified library headers and the bundle of
changes that I put in 9fix.patch.

I'd like to get the library headers in Nix
and hopefully even Plan 9 proper.  Then
there's only a handful of changes that I
need to get into the Go distribution.

It will happen. :-)

Cheers,
  Anthony

Re: [9fans] Building Go on Plan 9

[Anthony Martin]

erik quanstrom <quanstro@quanstro.net> once said:
> please just post again inline because 9fans.net
> doesn't archive attachments.

Sure thing.

---
A few people were asking about this so I
wrote up a tutorial.  I also uploaded a
copy to http://apm.sdf.org/go/NOTES for
anyone who has trouble with attachments.

Cheers,
  Anthony

# Building Go on Plan 9
# Anthony Martin
# ality@pbrane.org


# This document will guide you through the process
# of compiling the commands and packages in the Go
# source code distribution.
#
# Before we get started you should make sure you
# have GNU Make installed.  The version on contrib
# is 3.81 and is just fine for our purposes.
#
# It's also necessary to have Mercurial installed
# and I believe there is a version on contrib as
# well.
#
# After reading this document you can extract the
# commands and pipe them to the shell using:
#
#     sed -n 's,^[% ] ,,p' NOTES | rc
#
# I highly recommend reading all the way through
# before running the commands.
#

# First we must fetch the archive that contains
# modified include files, a build script, and a
# patch consisting of all pending (and not yet
# submitted) CLs pertaining to Plan 9.

% cd /tmp
% hget http://apm.sdf.org/go/root.tbz >root.tbz

# Next we must verify the SHA1 hash of the archive.

% want = ed25980b3b813b1c80506b56331d83c4d485a4c0
% have = `{sha1sum root.tbz | awk '{print $1}'}
% if(! ~ $have $want){
    echo 'ZOMG! INVALID SHA1 CHECKSUM'
    echo have: $have
    echo want: $want
    exit badhash
  }

# Now we're ready to fetch the source code for the
# Go repository hosted at Google Code.  I had to
# make a decision about where this would reside so
# after a bit of thinking I chose /sys/src/go to
# mirror the structure of APE.
#
# The other important directories that will be
# created when extracting the archive are:
#
#   /386/bin/go     (for binaries),
#   /386/include/go (for machine dependent C headers),
#   /386/lib/go     (for Go's C libraries),
#   and
#   /sys/include/go (for machine independent C headers).

% cd /sys/src
% hg clone -u 2d7711ae https://go.googlecode.com/hg/ go
requesting all changes
adding changesets
adding manifests
adding file changes
added 10641 changesets with 40432 changes to 5437 files (+4 heads)
updating to branch default
3231 files updated, 0 files merged, 0 files removed, 0 files unresolved

# After fetching the Go repository we can extract
# the archive into the file system's root.  It's
# always a good idea to check the contents of an
# archive before doing something this drastic.

% cd /
% tar xvzf /tmp/root.tbz
tar: blocking = 16
386
386/bin
386/bin/go
386/include
386/include/go
386/include/go/ureg_x86.h
386/include/go/ureg_amd64.h
386/include/go/u.h
386/include/go/ureg_arm.h
386/lib
386/lib/go
sys
sys/include
sys/include/go
sys/include/go/bootexec.h
sys/include/go/mach.h
sys/include/go/ar.h
sys/include/go/bio.h
sys/include/go/stdio.h
sys/include/go/libc.h
sys/include/go/goenv.h
sys/src
sys/src/go
sys/src/go/9fix.patch
sys/src/go/src
sys/src/go/src/make.rc

# We're almost done.  We can now apply the patch file
# into the root of the Go tree.

% cd /sys/src/go
% ape/patch -p1 < 9fix.patch

# Our final step is to build the commands and packages.
# Running make.rc will produce tons of output so you
# might want to redirect it to a file.

% cd src
% ./make.rc

# Now that you have a working build of Go you
# should help me make sure all of the tests pass. :-)
# Email me if you're interested in helping out.
#
# In other news, I'm working on setting up an
# an automated builder so we can include Plan 9
# in the Go Dashboard.
#
# Also, please don't submit any of the changes in
# the patch file to the Go development list.  Most
# of the changes have corresponding CLs and the few
# others are still being pondered.
#
# That's all for now.  Have fun!

Re: [9fans] Building Go on Plan 9

[Charles Forsyth]

modified library headers?

On 1 December 2011 18:14, Anthony Martin <ality@pbrane.org> wrote:
> a few
> modified library headers

Re: [9fans] Building Go on Plan 9

[Lyndon Nerenberg]

> modified library headers?

I stopped at gmake.  What can't mk do that demands gmake?

Re: [9fans] Building Go on Plan 9

[Anthony Martin]

Charles Forsyth <charles.forsyth@gmail.com> once said:
> modified library headers?

% ls (386 sys)^/include/go
386/include/go/u.h
386/include/go/ureg_amd64.h
386/include/go/ureg_arm.h
386/include/go/ureg_x86.h
sys/include/go/ar.h
sys/include/go/bio.h
sys/include/go/bootexec.h
sys/include/go/goenv.h
sys/include/go/libc.h
sys/include/go/mach.h
sys/include/go/stdio.h

Some of these are just copies of the standard
headers and others have a few adjustments that
the Go toolchain requires.  All except mach.h
have #pragmas that point to the stock location
in /386/lib/*.a.

  Anthony

Re: [9fans] Building Go on Plan 9

[erik quanstrom]

> 386/include/go/ureg_arm.h
> 386/include/go/ureg_x86.h

surely that's the wrong place.

- erik

Re: [9fans] Building Go on Plan 9

[Anthony Martin]

erik quanstrom <quanstro@quanstro.net> once said:
> > 386/include/go/ureg_arm.h
> > 386/include/go/ureg_x86.h
>
> surely that's the wrong place.

You would think so but that's how
where the headers are expected to
be for Go's libmach.

% gg 'include.*ureg'
src/cmd/cov/main.c:14: #include <ureg_x86.h>
src/cmd/prof/main.c:12: 	#include <ureg_amd64.h>
src/cmd/prof/main.c:15: 	#include <ureg_x86.h>
src/libmach/5.c:35: #include "ureg_arm.h"
src/libmach/5db.c:32: #include "ureg_arm.h"
src/libmach/6.c:35: #include "ureg_amd64.h"
src/libmach/8.c:34: #include <ureg_x86.h>
src/libmach/8db.c:34: #include <ureg_amd64.h>
src/libmach/8db.c:37: #include <ureg_x86.h>
src/libmach/darwin.c:33: #include <ureg_x86.h>
src/libmach/darwin.c:36: #include <ureg_amd64.h>
src/libmach/linux.c:42: #include <ureg_x86.h>
src/libmach/linux.c:45: #include <ureg_amd64.h>

Cheers,
  Anthony

Re: [9fans] Building Go on Plan 9

[Anthony Martin]

Anthony Martin <ality@pbrane.org> once said:
> You would think so but that's how
> where the headers are expected to
> be for Go's libmach.

"how where"?

I shouldn't type when tired.

  Anthony

Re: [9fans] Building Go on Plan 9

[Anthony Martin]

Lyndon Nerenberg <lyndon@orthanc.ca> once said:
> I stopped at gmake.  What can't mk do that demands gmake?

There's nothing wrong with mk.  It's just that
I highly doubt we could get a separate set of
mkfiles included in the Go distribution.

I've tried to get things going with the smallest
set of changes to both Plan 9 and Go and I think
using GNU Make is the only way to do that.

  Anthony

Re: [9fans] Building Go on Plan 9

[Lyndon Nerenberg]

> There's nothing wrong with mk.  It's just that
> I highly doubt we could get a separate set of
> mkfiles included in the Go distribution.

Have you tried?  It's a non-invasive change, and once they are set up it's
unlikely they will need to be updated often.

Re: [9fans] Building Go on Plan 9

[Lucio De Re]

>> There's nothing wrong with mk.  It's just that
>> I highly doubt we could get a separate set of
>> mkfiles included in the Go distribution.
>
> Have you tried?  It's a non-invasive change, and once they are set up it's
> unlikely they will need to be updated often.

I think Anthony is on the right path on this point, in that I've had
to update a couple of mkfiles in the recent past because I had
overlooked changes to the coresponding Makefiles.  Not many, but they
do trigger additional maintenance problems.

The only alternative option I would pick is to merge the Go release
into the Plan 9 (and nix) distribution - mkfiles and all - then use a
mechanism analogous to mine to keep them in sync.  The unsuspecting
public would never see the hard backroom effort.

In my fantasies, I see p9p as a stepping stone in that direction.

Lastly, my congratulations to Anthony, if there is any way I can
assist in merging the code, I'd be happy to help (just don't ask me to
install Python and Mercurial on my Plan 9 system - mind you, I'll
probably have to do so, sooner or later :-(.

Lucio.

Re: [9fans] Building Go on Plan 9

[ron minnich]

On Thu, Dec 1, 2011 at 11:54 AM, Lyndon Nerenberg <lyndon@orthanc.ca> wrote:
>> There's nothing wrong with mk.  It's just that
>> I highly doubt we could get a separate set of
>> mkfiles included in the Go distribution.
>
> Have you tried?  It's a non-invasive change, and once they are set up it's
> unlikely they will need to be updated often.
>
>

I've tried. The answer is "no". No mkfiles in the tree. I've not
watched this thread. Is this another totally different approach?

ron

Re: [9fans] Building Go on Plan 9

[Lucio De Re]

> I've tried. The answer is "no". No mkfiles in the tree. I've not
> watched this thread. Is this another totally different approach?

My understanding is that Anthony Martin is working on an APE angle.
If using APE suffices, I'm in favour of it, but I'm reserving
judgement until the issue is cleared.  I do expect complications, but
I'm sure they can be surmounted.

For my part, I prefer a mkfile approach that can be tracked by Bell
Labs and included in the official distribution.  I would be interested
in the approach Nemo might choose for nix.

++L

Re: [9fans] Building Go on Plan 9

[Francisco J Ballesteros]

Well, that's actually the approach Ron would choose for nix.
IIRC, there were a bunch of mkfiles added to the std. go tree
to make it compile, but I may be mistaken.
Ron knows better.


On Fri, Dec 2, 2011 at 7:42 AM, Lucio De Re <lucio@proxima.alt.za> wrote:
> I would be interested
> in the approach Nemo might choose for nix.

Re: [9fans] Building Go on Plan 9

[Anthony Martin]

Lucio De Re <lucio@proxima.alt.za> once said:
> > Have you tried?  It's a non-invasive change, and once they are set
> > up it's unlikely they will need to be updated often.
>
> I think Anthony is on the right path on this point, in that I've had
> to update a couple of mkfiles in the recent past because I had
> overlooked changes to the coresponding Makefiles.  Not many, but they
> do trigger additional maintenance problems.
>
> The only alternative option I would pick is to merge the Go release
> into the Plan 9 (and nix) distribution - mkfiles and all - then use a
> mechanism analogous to mine to keep them in sync.  The unsuspecting
> public would never see the hard backroom effort.

IMO using anything other than Make to build
the Go distribution is a fool's errand and
simply too much of a maintenance burden.
We would have to carefully watch upstream
changes to any of the many Makefiles.

Using make isn't as bad as some make it out
to be and, to be clear, I'm only advocating
the use of make to build the distribution;
we can still add rules for building tools
or libraries written in Go to the standard
mkfiles in /sys/src.

  Anthony

P.S.
I plan to switch from GNU Make to APE make
once I have the time to look closely at the
Go Makefiles for any GNU specific features
and then make the necessary changes or even
modify ape/make.

Re: [9fans] Building Go on Plan 9

[Pavel Zholkover]

Is the builder going to be based on the native build or will it be
cross-compiled ?

Thanks!

On Thu, Dec 1, 2011 at 8:18 PM, Anthony Martin <ality@pbrane.org> wrote:
# In other news, I'm working on setting up an
# an automated builder so we can include Plan 9
# in the Go Dashboard.

Re: [9fans] Building Go on Plan 9

[erik quanstrom]

> IMO using anything other than Make to build
> the Go distribution is a fool's errand and
> simply too much of a maintenance burden.
> We would have to carefully watch upstream
> changes to any of the many Makefiles.
>
> Using make isn't as bad as some make it out
> to be and, to be clear, I'm only advocating
> the use of make to build the distribution;
> we can still add rules for building tools
> or libraries written in Go to the standard
> mkfiles in /sys/src.

the camel has his nose in the tent.

- erik

Re: [9fans] Building Go on Plan 9

[Anthony Martin]

Pavel Zholkover <paulzhol@gmail.com> once said:
> Is the builder going to be based on the native
> build or will it be cross-compiled ?

It will be native.

  Anthony

Re: [9fans] Building Go on Plan 9

[Lyndon Nerenberg]

> I plan to switch from GNU Make to APE make
> once I have the time to look closely at the
> Go Makefiles for any GNU specific features
> and then make the necessary changes or even
> modify ape/make.

Go makefile use file inclusion and command execution in macro
assignments. I doubt APE make supports this as this isn't Posix
functionality. mk does.

Converting from GNUmakefile to mk isn't that hard.  If you look at the
existing Go makefiles you'll notice they are transliterations of the Plan
9 mk idioms to gmake.

Re: [9fans] Building Go on Plan 9

[Anthony Martin]

erik quanstrom <quanstro@quanstro.net> once said:
> > IMO using anything other than Make to build
> > the Go distribution is a fool's errand and
> > simply too much of a maintenance burden.
> > We would have to carefully watch upstream
> > changes to any of the many Makefiles.
> >
> > Using make isn't as bad as some make it out
> > to be and, to be clear, I'm only advocating
> > the use of make to build the distribution;
> > we can still add rules for building tools
> > or libraries written in Go to the standard
> > mkfiles in /sys/src.
>
> the camel has his nose in the tent.

This specific camel happens to be bearing
gifts on his nose.  I trust most 9fans to
keep the rest of him out. :-)

  Anthony

Re: [9fans] Building Go on Plan 9

[Lucio De Re]

> I plan to switch from GNU Make to APE make
> once I have the time to look closely at the
> Go Makefiles for any GNU specific features
> and then make the necessary changes or even
> modify ape/make.

I have had the most recent version of Gmake running as the APE tool of
choice, but I seem to have misplaced it.  Still, no need to treat
Gmake and ape/make as different, they should be close enough for all
intents and purposes.

In fact, compiling Gmake itself is not much of a mission, unlike bison.

++L

Re: [9fans] Building Go on Plan 9

[Lucio De Re]

> I have had the most recent version of Gmake running as the APE tool of
> choice, but I seem to have misplaced it.  Still, no need to treat
> Gmake and ape/make as different, they should be close enough for all
> intents and purposes.
>
> In fact, compiling Gmake itself is not much of a mission, unlike bison.

This is what I found:

	term% 8.out -v
	GNU Make 3.81
	Copyright (C) 2006  Free Software Foundation, Inc.
	This is free software; see the source for copying conditions.
	There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
	PARTICULAR PURPOSE.

	This program built for Plan 9/386

I'm not sure if there is a later version, it's been a long time since I looked.

++L

Re: [9fans] Building Go on Plan 9

[Skip Tavakkolian]

i think having Go is worth dealing with the beast.

On Fri, Dec 2, 2011 at 6:57 AM, erik quanstrom <quanstro@quanstro.net> wrote:
>> IMO using anything other than Make to build
>> the Go distribution is a fool's errand and
>> simply too much of a maintenance burden.
>> We would have to carefully watch upstream
>> changes to any of the many Makefiles.
>>
>> Using make isn't as bad as some make it out
>> to be and, to be clear, I'm only advocating
>> the use of make to build the distribution;
>> we can still add rules for building tools
>> or libraries written in Go to the standard
>> mkfiles in /sys/src.
>
> the camel has his nose in the tent.
>
> - erik
>

Re: [9fans] Building Go on Plan 9

[ron minnich]

On Fri, Dec 2, 2011 at 12:49 AM, Francisco J Ballesteros <nemo@lsub.org> wrote:
> Well, that's actually the approach Ron would choose for nix.
> IIRC, there were a bunch of mkfiles added to the std. go tree
> to make it compile, but I may be mistaken.
> Ron knows better.

My first hope was pretty much what others have said here: parallel
mkfiles to the Makefiles, because I expected they would change slowly
if at all. Andrey and I did get this going, and a simple
mk install
in go/src
sufficed to build and install all Go packages and produce some working
binaries, however that approach is not going to be accepted, because
it requires mkfiles in the Go source tree.

For the record, it takes a surprisingly small amount of effort to make
this work, once you know what is going on. Oh, and, there are some
bugs in the Go source that are uncovered when one builds on NIX. I've
submitted one fix and have one or two more in the works. The work has
not been in vain.

I think we need to be realistic about how much we can influence the Go
mainline source. I keep seeing comments on 9fans about how we can
change the way the Go source is written/built/managed, and those
comments envision some signiifcant changes. To repeat, I have been
told in no uncertain terms that changing the way Go is set up to
accommodate great Plan 9 ideas is just not going to happen, and that
our "footprint" in the Go source tree must remain very small. I think
that is the correct approach on the part of the Go team.

We have made minor changes on NIX to accomodate Go. Simple examples:
/*/mkfile
have an entry for the name of the Go compiler. There is a /go directory.

Based on the Python experience, where Plan 9's python is always far
behind the leading edge, I still believe that it is best if the
following always worked:

hg clone the-official-go-tree go
cd go/src
./some-shell-script

I do not think it makes sense to have Go source distributed as part of
the Plan 9 distro or contrib mechanism as that approach has not worked
well (in my view) for Python. Again, what I'd like to have is a Go
that always builds on Plan 9 from the mainline go source tree,
without having to dump in lots of patch files and other junk or change
the Makefiles. Andrey and I worked toward a "build with zero changes"
model. We did not get done and decided to wait for Go 1 anyway because
the number of Makefiles will be greatly reduced in Go 1 -- I expect
there will be less than 10 or so.

I believe the Go authors will accept a single shell script or two and
a go/9/include tree as part of the standard distro, so we need to
think in those terms. What I have in go/9/include today are some u.h
files, and that and a very simple set of changes should suffice to let
us build Go on Plan 9 with *zero* changes from the standard go source.

I hope that last paragraph was not too confusing.

Thanks

ron

Re: [9fans] Building Go on Plan 9

[ron minnich]

On Fri, Dec 2, 2011 at 6:33 AM, Anthony Martin <ality@pbrane.org> wrote:

> modify ape/make.

That strikes me as a good approach. The Go Makefiles do use very
standard Plan 9 like idioms but there are a few things they do that
looked gmake-dependent to me. There are very few of them however.

ron

Re: [9fans] Building Go on Plan 9

[Lyndon Nerenberg]

>> modify ape/make.

I was just waiting for this :-P

Please do NOT fuck with ape/make.  As the paper says, APE has become more
of a tool to write conforming ANSI / POSIX code vs. porting the stuff to
Plan 9.  Please don't take apes' virginity.

If people insist on inflicting gmake upon us, fine. I guess.  But please
(please?) don't screw the ape: deposit it in /$cputype/bin/gmake instead.

And now that the camel is firmly in the tent, we might as well
create a <foo>/camel hierarchy to parallel <foo>/ape, for all the
camel cruft (i.e. /$cputype/camel/make vs. /$cputype/bin/gmake).

Then, people who want to ride camels through the desert can run bsh(1) to
obtain a suitably inhospitable environment.  (bsh as in baking-hot shell,
although bs(1) seems like a reasonable alternative.)

Re: [9fans] Building Go on Plan 9

[Francisco J Ballesteros]

+1 for using parallel mkfiles.
If they are few, we don't need to import gmake and we could
still build just by adding them to the std tree.


On Fri, Dec 2, 2011 at 6:55 PM, Lyndon Nerenberg <lyndon@orthanc.ca> wrote:
>>> modify ape/make.
>
>
> I was just waiting for this :-P
>
> Please do NOT fuck with ape/make.  As the paper says, APE has become more of
> a tool to write conforming ANSI / POSIX code vs. porting the stuff to Plan
> 9.  Please don't take apes' virginity.
>
> If people insist on inflicting gmake upon us, fine. I guess.  But please
> (please?) don't screw the ape: deposit it in /$cputype/bin/gmake instead.
>
> And now that the camel is firmly in the tent, we might as well
> create a <foo>/camel hierarchy to parallel <foo>/ape, for all the camel
> cruft (i.e. /$cputype/camel/make vs. /$cputype/bin/gmake).
>
> Then, people who want to ride camels through the desert can run bsh(1) to
> obtain a suitably inhospitable environment.  (bsh as in baking-hot shell,
> although bs(1) seems like a reasonable alternative.)
>

Re: [9fans] Building Go on Plan 9

[Lyndon Nerenberg]

> (i.e. /$cputype/camel/make

Yes, I meant /$cputype/bin/camel/make.  You get the general idea ...

Re: [9fans] Building Go on Plan 9

[erik quanstrom]

> And now that the camel is firmly in the tent, we might as well
> create a <foo>/camel hierarchy to parallel <foo>/ape, for all the
> camel cruft (i.e. /$cputype/camel/make vs. /$cputype/bin/gmake).

shouldn't that be /tent and /$cputype/tent
the camels sneak in the tent, not the other way around.

- erik

Re: [9fans] Building Go on Plan 9

[ron minnich]

On Fri, Dec 2, 2011 at 9:58 AM, Francisco J Ballesteros <nemo@lsub.org> wrote:
> +1 for using parallel mkfiles.

as I say, I liked this too, but it fails the zero changes rule.

But we'll let the guys doing the work make the rules. First one to
produce a useable Go tree wins -- if, that is, they make updates
from the mainline go tree easy.

Be aware that no go tree I know of passes the Go test suite, yet. Lots
of fun ahead.

Anthony, you do know that there is a mk based version of Go that builds, right?

ron

[9fans] go v. mk

[Lyndon Nerenberg]

My freebsd-current flamewar is dying out, so time for something new ...

Why are parallel mkfiles in the /go tree considered eeevil?  They seemed
to be very low overhead.  Surely accomodations are being made for Windows.

Regardless, if we want native go, is it that unreasonable to maintain a
port ala spin?  My fiddling with the go tree makes me think it isn't that
hard to set up an overlay that adopts the live go tree to what Plan9 needs
for a build.  bind(1) is a wonderful thing -- we should use it!

The most dynamic part of the go source tree these days seems to be
pkg/Makefile (as far as a native build is concerned).  It can't be that
hard to parse out DIR= from there and turn it into a native mkfile.

Re: [9fans] go v. mk

[ron minnich]

nobody is stopping you from doing anything. go for it.

ron

Re: [9fans] Building Go on Plan 9

[erik quanstrom]

On Fri Dec  2 13:21:09 EST 2011, rminnich@gmail.com wrote:
> On Fri, Dec 2, 2011 at 9:58 AM, Francisco J Ballesteros <nemo@lsub.org> wrote:
> > +1 for using parallel mkfiles.
>
> as I say, I liked this too, but it fails the zero changes rule.

if the rule is literally "zero change", then we should give up now.

- erik

Re: [9fans] Building Go on Plan 9

[andrey mirtchovski]

> if the rule is literally "zero change", then we should give up now.

Russ has been most accommodating with changes in the Go tree. As far
as go portability to Plan 9 is concerned, that's not a problem (except
the few actual problems that need fixing, but that's just code). The
issue is polluting the go tree with yet another build framework which
is 1) not really necessary, 2) about to be taken out anyway and 3)
possible to devise programatically. Russ has said privately (jokingly)
that he'd accept mkfiles if each one said "|<$GOROOT/mkmk.rc Makefile"
and, knowing what we know now, it's not impossible to do.
rminnich-9go's mkfiles for the go package library were mostly created
with such a script.

more important issues exist than just how to build go (which boils
down to "pick any of the 3 current methods and go for it") -- for
example, in order to complete running the full test suite one needs to
solve a signal handling bug in the plan9-specific code of the go
runtime.

Re: [9fans] Building Go on Plan 9

[andrey mirtchovski]

s/that's just code/"that's just code"/ in my previous email.

Re: [9fans] go v. mk

[Steve Simon]

>  It can't be that
> hard to parse out DIR= from there and turn it into a native mkfile.

Ok, its not that simple but perhaps somthing along the lines of
/sys/src/cmd/mk/mkconv could help?

-Steve

Re: [9fans] go v. mk

[Lyndon Nerenberg]

> Ok, its not that simple but perhaps somthing along the lines of
> /sys/src/cmd/mk/mkconv could help?

/^DIR=,^$/...

Re: [9fans] go v. mk

[ron minnich]

On Fri, Dec 2, 2011 at 4:06 PM, Steve Simon <steve@quintile.net> wrote:
>>  It can't be that
>> hard to parse out DIR= from there and turn it into a native mkfile.
>
> Ok, its not that simple but perhaps somthing along the lines of
> /sys/src/cmd/mk/mkconv could help?

Did you try it? Might be worth trying it. We did. But maybe it's time
to try things first and then send email :-)

ron

Re: [9fans] go v. mk

[Federico Benavento]

On Dec 2, 2011, at 9:12 PM, ron minnich wrote:

> Did you try it? Might be worth trying it. We did. But maybe it's time
> to try things first and then send email :-)

relax, maybe he didn't, but he did write a tool that parses configure/makefiles
and generates mkfilles

Re: [9fans] go v. mk

[John Floren]

On Sun, Dec 4, 2011 at 4:32 PM, Federico Benavento <benavento@gmail.com> wrote:
>
> On Dec 2, 2011, at 9:12 PM, ron minnich wrote:
>
>> Did you try it? Might be worth trying it. We did. But maybe it's time
>> to try things first and then send email :-)
>
> relax, maybe he didn't, but he did write a tool that parses configure/makefiles
> and generates mkfilles
>
>

What's it called? Where can I get it? Sounds pretty useful.


John

Re: [9fans] go v. mk

[Federico Benavento]

mkmk

On Dec 4, 2011, at 9:44 PM, John Floren wrote:

> On Sun, Dec 4, 2011 at 4:32 PM, Federico Benavento <benavento@gmail.com> wrote:
>> 
>> On Dec 2, 2011, at 9:12 PM, ron minnich wrote:
>> 
>>> Did you try it? Might be worth trying it. We did. But maybe it's time
>>> to try things first and then send email :-)
>> 
>> relax, maybe he didn't, but he did write a tool that parses configure/makefiles
>> and generates mkfilles
>> 
>> 
> 
> What's it called? Where can I get it? Sounds pretty useful.
> 
> 
> John
> 

Re: [9fans] go v. mk

[Aram Hăvărneanu]

Lyndon Nerenberg  wrote:
> Why are parallel mkfiles in the /go tree considered eeevil?  They seemed to
> be very low overhead.  Surely accomodations are being made for Windows.
>
> [...] My fiddling with the go tree makes me think it isn't that hard to
> set up an overlay that adopts the live go tree to what Plan9 needs for a
> build.  bind(1) is a wonderful thing -- we should use it!
>
> [...] It can't be that hard
> to parse out DIR= from there and turn it into a native mkfile.

I'm very late in the discussion, but I'd like to point out that Go is
already using the go build tool instead of makefiles, at least for
some part of the tree.  I believe this simplifies things greatly.  No
makefiles to maintain or generate.

-- 
Aram Hăvărneanu

Re: [9fans] Building Go on Plan 9

[lsub]

send a change to nix-dev to include the se headers.
the process file describes how to do it.

Another alternative is to make a contrib package for nix
that could be installed with pm.

Perhaps that's a better option.

--
using ipad keyboard. excuse any typos.


On Dec 1, 2011, at 7:29 PM, ality@pbrane.org wrote:

> Charles Forsyth <charles.forsyth@gmail.com> once said:
>> modified library headers?
>
> % ls (386 sys)^/include/go
> 386/include/go/u.h
> 386/include/go/ureg_amd64.h
> 386/include/go/ureg_arm.h
> 386/include/go/ureg_x86.h
> sys/include/go/ar.h
> sys/include/go/bio.h
> sys/include/go/bootexec.h
> sys/include/go/goenv.h
> sys/include/go/libc.h
> sys/include/go/mach.h
> sys/include/go/stdio.h
>
> Some of these are just copies of the standard
> headers and others have a few adjustments that
> the Go toolchain requires. All except mach.h
> have #pragmas that point to the stock location
> in /386/lib/*.a.
>
> Anthony
>
> [/mail/box/nemo/msgs/201112/50]