List of required build tools incomplete.

[gopherbot]

by achowe@snertsoft.com:

http://golang.org/doc/install.html#tmp_53

1. bison requires m4 or gm4

2. build process assumes that "make" is gmake.

3. build process assumes bash installed, install of coding for POSIX.2
shell portability

[rsc]

Comment 1:

I understand points 2 and 3.
In point 1, are you saying that after installing bison, it doesn't run properly unless
m4 is 
also installed?
If this is the case, this seems like a bug in bison's dependency list in the package 
manager on your Linux system.

Owner changed to r...@golang.org.

Status changed to WaitingForReply.

[gopherbot]

Comment 2 by kimelto:

I agree, /bin/sh and bsdmake compability would be a step forward for portability
concerns.

[gopherbot]

Comment 3 by achowe@snertsoft.com:

You're assuming that I'm building on linux and using a package system, where in fact
I'm trying to port Go to OpenBSD 4.0 and not using the package system; instead,
installing Bison from source distro. Thankfully I build sendmail regularly from
source and it relies on m4, though Bison appears to depend on gm4. This is why I've
brought up the portability and requirements issues.
OpenBSD defaults to a POSIX conforming shell (public domain Korn shell) and the make
supports many of the conditionals, but prefixed with dot, ie. .ifdef instead of just
ifndef. I don't know if gmake recognises both .ifdef and ifdef, if so, then it would
be best to use the common syntax.
The shell and makefiles should make use of macros for tool names like $BASH, $MAKE,
etc so that they can be substituted easily.
Also I think I've discovered a dependency on gcc 4 vs my system's older gcc 3.3.5;
though I'm still working on that (godefs doesn't appear to work).

[rsc]

Comment 4:

Thanks for your comments.  
We're not going to try for /bin/sh and make compatibility just now:
there are many different sh and make implementations out there,
and it's too hard for us to test them all.  Instead, we reworked the
build scripts to use bash and GNU make always, so that we need only
worry about portability across different versions of a single program.
As of http://code.google.com/p/go/source/detail?r=692ac2ced6f7
the build process should run on BSD machines as long as bash and
gmake are installed in one of the standard locations, so that should
be a help.
I expect that FreeBSD support will be checked in tomorrow or the
next day (it is very close to working); perhaps that will be a useful
starting point for OpenBSD.  You can follow issue #166 for more.
https://golang.org/issue/166
I'm not going to list the m4 dependency in the package documentation,
since that is only an indirect dependency due to Bison, not a direct
dependency of Go.
I would certainly be interested to know about and correct a dependency
of godefs on gcc 4.

Status changed to Fixed.

[gopherbot]

Comment 5 by achowe@snertsoft.com:

No need to test all the shells, just go for POSIX compatibility, which is the whole
point of the standard, which documented Bourne shell semantics. If you use GNU
autoconf, they understand portability and handle all the shell and C portability
issues very well. At the very least in bash use "set -o posix".
The godefs dependency on gcc 4 is: 
a) Remove -c option, since usage says -c|-S|-E are mutually exclusive.
b) gcc 3.3.5 does NOT support "-o-", instead you need to do "-o -", which in godefs
requires splitting the option and parameter over two entries in av[]. This will be
part of my patch set.

[gopherbot]

Comment 6 by achowe@snertsoft.com:

Also avoid bash-isms in src/pkg/syscall/mkerrors.sh:
-       indirect="includes_$(uname)"
-       echo "${!indirect} $includes"
More portable:
+       name="includes_${uname}"
+       eval indirect=\$$name
+       echo "${indirect} $includes"

[rsc]

Comment 7:

This issue was closed by revision 39f64be.

Merged into issue #-.