Re: Patch RFA: Support for building Go tools

2015-01-15 Thread Ian Lance Taylor
On Wed, Jan 14, 2015 at 11:07 AM, Uros Bizjak ubiz...@gmail.com wrote:

 This patch adds support to the GCC tree for building tools that are
 used with Go.  There are two external used tools (go, gofmt) and one
 tool used internally by go (cgo).  This patch is pure machinery, with
 no source code.  The tools are not built by default, only when go is
 enabled using --enable-languages.  For the moment the tools are also
 not built when building a cross-compiler, although I hope to change
 that when I figure out what is needed.

 Attached is the patch that enables gotools on alpha/linux.

 Tested on alpha-linux-gnu, cgo, go and gofmt executables run without problems.

Thanks.  Committed.

Ian


Re: Patch RFA: Support for building Go tools

2015-01-14 Thread Uros Bizjak
Hello!

 This patch adds support to the GCC tree for building tools that are
 used with Go.  There are two external used tools (go, gofmt) and one
 tool used internally by go (cgo).  This patch is pure machinery, with
 no source code.  The tools are not built by default, only when go is
 enabled using --enable-languages.  For the moment the tools are also
 not built when building a cross-compiler, although I hope to change
 that when I figure out what is needed.

Attached is the patch that enables gotools on alpha/linux.

Tested on alpha-linux-gnu, cgo, go and gofmt executables run without problems.

Uros.

--cut here--
Index: go/go/build/build.go
===
--- go/go/build/build.go(revision 219515)
+++ go/go/build/build.go(working copy)
@@ -266,6 +266,7 @@ var cgoEnabled = map[string]bool{
freebsd/amd64:   true,
freebsd/arm: true,
linux/386:   true,
+   linux/alpha: true,
linux/amd64: true,
linux/arm:   true,
linux/ppc64: true,
--cut here--


Re: Patch RFA: Support for building Go tools

2015-01-09 Thread Paolo Bonzini


On 09/01/2015 15:24, Ian Lance Taylor wrote:
 
  This should work automatically, the only difference is that you must
  omit $(LIBGODEP) from the dependencies.
 What will happen if there is no installed gccgo at the right version?

Compilation fails.

 What should happen?

Compilation fails. :)

 I haven't been keeping track--will the build machinery now build a
 build-x-host Go compiler?

No, but the build machinery should point the Makefile variables to a
build-x-host tool from the PATH.  If it doesn't, you need to modify the
toplevel configure.ac and Makefile.tpl.

Paolo


Re: Patch RFA: Support for building Go tools

2015-01-09 Thread Paolo Bonzini


On 08/01/2015 22:35, Ian Lance Taylor wrote:
 
 +if NATIVE
 +
 +# For a native build we build the programs using the newly built libgo
 +# and install them as regular programs.
 +
 +bin_PROGRAMS = go$(EXEEXT) gofmt$(EXEEXT)
 +libexecsub_PROGRAMS = cgo$(EXEEXT)
 +
 +go$(EXEEXT): $(go_cmd_go_files) zdefaultcc.go $(LIBGODEP)
 + $(GOLINK) $(go_cmd_go_files) zdefaultcc.go
 +gofmt$(EXEEXT): $(go_cmd_gofmt_files) $(LIBGODEP)
 + $(GOLINK) $(go_cmd_gofmt_files)
 +cgo$(EXEEXT): $(go_cmd_cgo_files) zdefaultcc.go $(LIBGODEP)
 + $(GOLINK) $(go_cmd_cgo_files) zdefaultcc.go
 +
 +else
 +
 +# For a non-native build we have to build the programs using a
 +# previously built host (or build - host) Go compiler.  We should
 +# only do this if such a compiler is available.  Figure this out
 +# later.
 +
 +endif

This should work automatically, the only difference is that you must
omit $(LIBGODEP) from the dependencies.

 +AC_PROG_CC
 +AC_PROG_GO
 +
 +AM_CONDITIONAL(NATIVE, test $host_noncanonical = $target_noncanonical)

Can you check $cross_compiling = no instead?

Looks good apart for these two nits.

Paolo


Re: Patch RFA: Support for building Go tools

2015-01-09 Thread Ian Lance Taylor
On Fri, Jan 9, 2015 at 7:40 AM, Paolo Bonzini bonz...@gnu.org wrote:


 On 09/01/2015 15:24, Ian Lance Taylor wrote:
 
  This should work automatically, the only difference is that you must
  omit $(LIBGODEP) from the dependencies.
 What will happen if there is no installed gccgo at the right version?

 Compilation fails.

 What should happen?

 Compilation fails. :)

 I haven't been keeping track--will the build machinery now build a
 build-x-host Go compiler?

 No, but the build machinery should point the Makefile variables to a
 build-x-host tool from the PATH.  If it doesn't, you need to modify the
 toplevel configure.ac and Makefile.tpl.

I forgot: there is another problem with using the build-x-host
compiler to build the tools.  That will build them with the host
version of the go/build package, which will set the default values for
the architecture and OS to be that of the host, not the target.  They
should really be the target.  We can fix this, but it will require
some thought.

I plan to commit the version that does not do anything when building a
cross-compiler in order to proceed.  The situation will not be worse
than it is today.

Ian


Re: Patch RFA: Support for building Go tools

2015-01-09 Thread Ian Lance Taylor
Committed initial gotools patch with following ChangeLog entries:

./:

2015-01-09  Ian Lance Taylor  i...@google.com

* configure.ac (host_tools): Add gotools.
* Makefile.def (host_modules): Add gotools.
(dependencies): Add dependency of all-gotools on all-target-libgo.

gcc/go/:

2015-01-09  Ian Lance Taylor  i...@google.com

* config-lang.in (lang_dirs): Define.

gotools/:

2015-01-09  Ian Lance Taylor  i...@google.com

* Initial implementation.


Re: Patch RFA: Support for building Go tools

2015-01-09 Thread Ian Lance Taylor
On Fri, Jan 9, 2015 at 12:54 AM, Paolo Bonzini bonz...@gnu.org wrote:

 +
 +# For a non-native build we have to build the programs using a
 +# previously built host (or build - host) Go compiler.  We should
 +# only do this if such a compiler is available.  Figure this out
 +# later.
 +
 +endif

 This should work automatically, the only difference is that you must
 omit $(LIBGODEP) from the dependencies.

What will happen if there is no installed gccgo at the right version?
What should happen?

I haven't been keeping track--will the build machinery now build a
build-x-host Go compiler?

Ian


Re: Patch RFA: Support for building Go tools

2015-01-08 Thread pinskia




 On Jan 8, 2015, at 1:35 PM, Ian Lance Taylor i...@golang.org wrote:
 
 This patch adds support to the GCC tree for building tools that are
 used with Go.  There are two external used tools (go, gofmt) and one
 tool used internally by go (cgo).  This patch is pure machinery, with
 no source code.  The tools are not built by default, only when go is
 enabled using --enable-languages.  For the moment the tools are also
 not built when building a cross-compiler, although I hope to change
 that when I figure out what is needed.

When you add support for cross, please also make sure that Canadian cross works 
too. 

Thanks,
Andrew

 
 The tools work just as they do when built for the gc compiler, only
 they use gccgo instead of gc.  For documentation on these tools and
 what they do see http://golang.org/cmd/go ,
 http://golang.org/cmd/gofmt , http://golang.org/cmd/cgo .
 
 This patch parallels the mechanism used in the existing gnattools
 directory for building Ada tools.
 
 Could the build machinery maintainers please take a look and let me
 know if this is OK?  Thanks.
 
 Lynn, please also take a look and see if this works for you.
 
 The first attachment is the real changes for review.  The second
 attachment is a compressed patch for the generated files, for
 convenience for anybody who wants to try this out.
 
 Ian
 foo.txt
 foo1.txt.bz2