Re: PATCH RFA: Add Go support

2010-12-19 Thread Ralf Wildenhues 
Hello Ian,

I have pushed your patch to the Libtool git tree now, with GCCGO
replaced by GOC and some whitespace changes, and your two patches
squashed in one, as below.  Sorry for the delay.

Thanks,
Ralf

2010-12-20  Ian Lance Taylor  i...@google.com

* libltdl/m4/libtool.m4 (LT_LANG): Add Go.
(AC_PROG_GO): Provide.
(_LT_SYS_HIDDEN_LIBDEPS): Add Go case.
(_LT_LANG_GO_CONFIG): Define.
(LT_PROG_GO): Define.
(AC_PROG_GO): Define if not defined.
* libltdl/config/ltmain.m4sh: Match *.go.
* doc/libtool.texi (LT_INIT): Mention Go.
(Tags): Mention Go.
* configure.ac: Enable Go.
* NEWS: Update.

diff --git a/NEWS b/NEWS
index 8d6965d..96c9723 100644
--- a/NEWS
+++ b/NEWS
@@ -8,6 +8,8 @@ New in 2.4.2 2010-12-??: git version 2.4.1a, Libtool team:
 package names.  This can be used to build some static libraries with PIC
 objects while building others with non-PIC objects.
 
+  - Initial support for Go, using the gccgo compiler.
+
 * Bug fixes:
 
   - The generic approximation of the command line length limit (when getconf is
diff --git a/configure.ac b/configure.ac
index 63ee8bf..0bad772 100644
--- a/configure.ac
+++ b/configure.ac
@@ -196,6 +196,7 @@ _LTDL_SETUP
 LT_LANG(C++)
 LT_LANG(Fortran 77)
 LT_LANG(Fortran)
+LT_LANG(Go)
 LT_LANG(Java)
 LT_LANG(Windows Resource)
 
diff --git a/doc/libtool.texi b/doc/libtool.texi
index 04c5507..4823ab8 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -2250,7 +2250,7 @@ specifying @option{--with-pic} to @command{configure}.
 @defmac LT_LANG (@var{language})
 Enable @command{libtool} support for the language given if it
 has not yet already been enabled.  Languages accepted are ``C++'',
-``Fortran 77'', ``Java'' and ``Windows Resource''.
+``Fortran 77'', ``Java'', ``Go'', and ``Windows Resource''.
 
 If Autoconf language support macros such as @code{AC_PROG_CXX} are
 used in your @file{configure.ac}, Libtool language support will automatically
@@ -2849,6 +2849,7 @@ correspondence between language names and tags names.
 @item Java @tab GCJ
 @item Fortran 77   @tab F77
 @item Fortran  @tab FC
+...@item Go   @tab GO
 @item Windows Resource @tab RC
 @end multitable
 
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index aff8a1c..8c37f88 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -1270,7 +1270,7 @@ func_mode_compile ()
 *.[cCFSifmso] | \
 *.ada | *.adb | *.ads | *.asm | \
 *.c++ | *.cc | *.ii | *.class | *.cpp | *.cxx | \
-*.[fF][09]? | *.for | *.java | *.obj | *.sx | *.cu | *.cup)
+*.[fF][09]? | *.for | *.java | *.go | *.obj | *.sx | *.cu | *.cup)
   func_xform $libobj
   libobj=$func_xform_result
   ;;
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 21b12fd..8e88917 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -803,6 +803,7 @@ AC_DEFUN([LT_LANG],
 m4_case([$1],
   [C], [_LT_LANG(C)],
   [C++],   [_LT_LANG(CXX)],
+  [Go],[_LT_LANG(GO)],
   [Java],  [_LT_LANG(GCJ)],
   [Fortran 77],[_LT_LANG(F77)],
   [Fortran],   [_LT_LANG(FC)],
@@ -824,6 +825,31 @@ m4_defun([_LT_LANG],
 ])# _LT_LANG
 
 
+m4_ifndef([AC_PROG_GO], [
+
+# NOTE: This macro has been submitted for inclusion into   #
+#  GNU Autoconf as AC_PROG_GO.  When it is available in#
+#  a released version of Autoconf we should remove this#
+#  macro and use it instead.   #
+
+m4_defun([AC_PROG_GO],
+[AC_LANG_PUSH(Go)dnl
+AC_ARG_VAR([GOC], [Go compiler command])dnl
+AC_ARG_VAR([GOFLAGS], [Go compiler flags])dnl
+_AC_ARG_VAR_LDFLAGS()dnl
+AC_CHECK_TOOL(GOC, gccgo)
+if test -z $GOC; then
+  if test -n $ac_tool_prefix; then
+AC_CHECK_PROG(GOC, [${ac_tool_prefix}gccgo], [${ac_tool_prefix}gccgo])
+  fi
+fi
+if test -z $GOC; then
+  AC_CHECK_PROG(GOC, gccgo, gccgo, false)
+fi
+])#m4_defun
+])#m4_ifndef
+
+
 # _LT_LANG_DEFAULT_CONFIG
 # ---
 m4_defun([_LT_LANG_DEFAULT_CONFIG],
@@ -854,6 +880,10 @@ AC_PROVIDE_IFELSE([AC_PROG_GCJ],
m4_ifdef([LT_PROG_GCJ],
[m4_define([LT_PROG_GCJ], defn([LT_PROG_GCJ])[LT_LANG(GCJ)])])])])])
 
+AC_PROVIDE_IFELSE([AC_PROG_GO],
+  [LT_LANG(GO)],
+  [m4_define([AC_PROG_GO], defn([AC_PROG_GO])[LT_LANG(GO)])])
+
 AC_PROVIDE_IFELSE([LT_PROG_RC],
   [LT_LANG(RC)],
   [m4_define([LT_PROG_RC], defn([LT_PROG_RC])[LT_LANG(RC)])])
@@ -6916,6 +6946,11 @@ public class foo {
   }
 };
 _LT_EOF
+], [$1], [GO], [cat  conftest.$ac_ext _LT_EOF
+package foo
+func foo() {
+}
+_LT_EOF
 ])
 
 _lt_libdeps_save_CFLAGS=$CFLAGS
@@ -7437,6 +7472,77 @@ CFLAGS=$lt_save_CFLAGS
 ])# _LT_LANG_GCJ_CONFIG
 
 
+# _LT_LANG_GO_CONFIG([TAG])
+# --
+# Ensure that the configuration

Re: PATCH RFA: Add Go support

2010-11-01 Thread Ian Lance Taylor 
Ralf Wildenhues ralf.wildenh...@gmx.de writes:

 OK.  So IIUC one example dependency graph would be something like this:

   ( sin.go cos.go exp.go ) - math.OBJEXT - libfem.so
   ( grid.go solver.go )- sub/pdesolve.OBJEXT ---^

 where the sets of .go files are distinct, the sets of object files
 (packages) cannot be derived from their inputs (neither their names
 nor their contents?) but rather specified only in the makefile, and
 objects are subsumed in (static or shared) libraries or in programs
 as usual.  OBJEXT may be o or obj (for w32) or lo (for libtool).

That is essentially correct.  The source file does include the name of
the package.  E.g., your example, each of sin.go, cos.go, and exp.go
would start with package math.  There is no necessary connection
between the name used in the source file and the name of the object
file.  But it would certainly be conventional to use the same name for
the package name and the object file name.

 We need a bit of new notation for this, and we need to teach automake
 about languages that shouldn't have renamed objects even in the presence
 of per-object flags.

Hmmm, no, the objects can be renamed.  The agreement between source
level package name and file level package name is by convention only.


  What if files reside in subdirs (of the current directory, or of
  $srcdir), will objects be created in subdirs or in the current directory
  (and how would we avoid creation of files below $srcdir in a VPATH
  build, given that $srcdir is a concept not known to the compiler a
  priori)?  Or maybe it has no objects at all?
 
 Only one object file is created for each package.  It can go wherever.

 Should a package be an installable entity?  At that point we should
 think about using a separate new _PRIMARY for it.

A package can be installable by itself, sure.


  Can the user split up large projects into multiple pieces, either by
  separate Makefile.am files for separate directories, or somehow
  separately compiling the set of sources in one directory, maybe by
  library or by program compiled?
 
 Sure.
 
  If the latter is to be supported, then
  things like overlapping sources become a problem (i.e., both libfoo and
  libbar use baz.o).
 
 That can not happen, because baz.go can only be in one package.

 Setups like the following are not possible in theory?

 if WANT_FEATURE_IN_FOO
 foo_lo_SOURCES += baz.go
 else
 if WANT_FEATURE_IN_BAR
 bar_lo_SOURCES += baz.go
 endif
 endif

Right, that is not possible, unless foo.lo and bar.lo define the same
package, which would be very odd.

Ian

Re: PATCH RFA: Add Go support

2010-10-13 Thread Ian Lance Taylor 
Ralf Wildenhues ralf.wildenh...@gmx.de writes:

 * Ian Lance Taylor wrote on Tue, Oct 12, 2010 at 11:42:56PM CEST:
 This patch adds support for the Go programming language to libtool.  Go
 is described at http://golang.org/ .
 
 I'm not very familiar with libtool.  This patch is mostly a
 cut-and-paste job.  It is enough to let me use automake with LIBTOOL to
 build libraries from Go code.

 Do you have, or are working on, an Automake patch for Go support?

I do not have an automake patch, although that is a logical next step.
I've been using libtool with a Makefile.am which uses this definition:

LTGOCOMPILE = $(LIBTOOL) --tag GO --mode=compile $(GCCGO) $(INCLUDES) \
$(AM_GOFLAGS) $(GOFLAGS)

and then runs $(LTGOCOMPILE) as needed.  Adding Go support to automake
may be a little tricky as Go requires a slightly different compilation
model: you must pass all files that are in the same package to the
compiler at once.  You can't compile them separately.


 The patch requires a patch which I've proposed for autoconf:
 
 http://lists.gnu.org/archive/html/autoconf-patches/2010-10/msg4.html
 
 I'm not sure how to handle a libtool patch which requires an autoconf
 patch.  Perhaps this can not be committed until the next libtool
 release.

 We usually try to support older Autoconf as well (currently back to
 2.59), so that people don't need to upgrade all at once.  When only
 macros from Autoconf proper are missing (as opposed to macros from other
 third parties), they can be treated similarly to how AC_PROG_SED is
 treated with a backup in libtool.m4.

Done.

 In any case I would appreciate any comments and any advice as to how to
 get this committed to libtool.  Thanks.

 tests/suffix.test should be updated.

Dont.

 Can you send output of
   ./libtool --tag=GO --config

 for Libtool with Go support enabled?  You need to patch Libtool's
 configure.ac to enable Go support (this should be part of the patch as
 well).

Attached.

 A NEWS entry would be good.

Done.

 Testsuite additions (to the new testsuite)
 would be nice, like one setup where Go is the only language enabled (to
 verify that object and executable extension computation work etc).
 We can write those tests if you're not familiar with Autotest.

Can you suggest a test that I can look at to see what this should look
like?

Updated patch attached (two patches from git format-patch, let me know
if there is a better way to send this).

Ian


# Which release of libtool.m4 was used?
macro_version=2.4.1a
macro_revision=1.3300

# Assembler program.
AS=as

# DLL creation program.
DLLTOOL=false

# Object dumper program.
OBJDUMP=objdump

# Whether or not to build shared libraries.
build_libtool_libs=yes

# Whether or not to build static libraries.
build_old_libs=yes

# What type of objects to build.
pic_mode=default

# Whether or not to optimize for fast installation.
fast_install=yes

# Shell to use when invoking shell scripts.
SHELL=/bin/sh

# An echo program that protects backslashes.
ECHO=printf %s\\n

# The host system.
host_alias=
host=x86_64-unknown-linux-gnu
host_os=linux-gnu

# The build system.
build_alias=
build=x86_64-unknown-linux-gnu
build_os=linux-gnu

# A sed program that does not truncate output.
SED=/bin/sed

# Sed that helps us avoid accidentally triggering echo(1) options like -n.
Xsed=$SED -e 1s/^X//

# A grep program that handles long lines.
GREP=/bin/grep

# An ERE matcher.
EGREP=/bin/grep -E

# A literal string matcher.
FGREP=/bin/grep -F

# A BSD- or MS-compatible name lister.
NM=/usr/bin/nm -B

# Whether we need soft or hard links.
LN_S=ln -s

# What is the maximum length of a command?
max_cmd_len=1572864

# Object file suffix (normally o).
objext=o

# Executable file suffix (normally ).
exeext=

# whether the shell understands unset.
lt_unset=unset

# turn spaces into newlines.
SP2NL=tr \\040 \\012

# turn newlines into spaces.
NL2SP=tr \\015\\012 \\040\\040

# convert $build file names to $host format.
to_host_file_cmd=func_convert_file_noop

# convert $build files to toolchain format.
to_tool_file_cmd=func_convert_file_noop

# Method to check whether dependent libraries are shared objects.
deplibs_check_method=pass_all

# Command to use when deplibs_check_method = file_magic.
file_magic_cmd=\$MAGIC_CMD

# How to find potential files when deplibs_check_method = file_magic.
file_magic_glob=

# Find potential files using nocaseglob when deplibs_check_method = 
file_magic.
want_nocaseglob=no

# Command to associate shared and link libraries.
sharedlib_from_linklib_cmd=printf %s\\n

# The archiver.
AR=ar

# Flags to create an archive.
AR_FLAGS=cru

# How to feed a file listing to the archiver.
archiver_list_spec=@

# A symbol stripping program.
STRIP=strip

# Commands used to install an old-style archive.
RANLIB=ranlib
old_postinstall_cmds=chmod 644 \$oldlib~\$RANLIB \$oldlib
old_postuninstall_cmds=

# Whether to use a lock for old archive extraction.
lock_old_archive_extraction=no

# A C compiler.
LTCC=gcc

# LTCC compiler

Re: PATCH RFA: Add Go support

2010-10-13 Thread Ralf Wildenhues 
* Ian Lance Taylor wrote on Wed, Oct 13, 2010 at 07:31:04PM CEST:
 Ralf Wildenhues writes:
  Do you have, or are working on, an Automake patch for Go support?
 
 I do not have an automake patch, although that is a logical next step.
 I've been using libtool with a Makefile.am which uses this definition:
 
 LTGOCOMPILE = $(LIBTOOL) --tag GO --mode=compile $(GCCGO) $(INCLUDES) \
   $(AM_GOFLAGS) $(GOFLAGS)
 
 and then runs $(LTGOCOMPILE) as needed.  Adding Go support to automake
 may be a little tricky as Go requires a slightly different compilation
 model: you must pass all files that are in the same package to the
 compiler at once.  You can't compile them separately.

That is not a big problem per se.  However, how would you implement
build parallelism?  Inside gccgo?  Should it eventually have jobserver
support, received from make?

What if files reside in subdirs (of the current directory, or of
$srcdir), will objects be created in subdirs or in the current directory
(and how would we avoid creation of files below $srcdir in a VPATH
build, given that $srcdir is a concept not known to the compiler a
priori)?  Or maybe it has no objects at all?

Can the user split up large projects into multiple pieces, either by
separate Makefile.am files for separate directories, or somehow
separately compiling the set of sources in one directory, maybe by
library or by program compiled?  If the latter is to be supported, then
things like overlapping sources become a problem (i.e., both libfoo and
libbar use baz.o).

  Can you send output of
./libtool --tag=GO --config
 
  for Libtool with Go support enabled?  You need to patch Libtool's
  configure.ac to enable Go support (this should be part of the patch as
  well).
 
 Attached.

Thanks, that looks quite reasonable.

  Testsuite additions (to the new testsuite)
  would be nice, like one setup where Go is the only language enabled (to
  verify that object and executable extension computation work etc).
  We can write those tests if you're not familiar with Autotest.
 
 Can you suggest a test that I can look at to see what this should look
 like?

Off-hand I don't know an ideal candidate, but you can look at
template.at for a way to do it manually (by using the libtool script
generated in the toplevel, and not using Automake) would give coverage
of compile and link mode.

For a complete configure example, you need to setup at least a minimal
configure.ac, and run LT_AT_AUTOCONF, LT_AT_CONFIGURE etc.  The helper
macros are defined in tests/testsuite.at.  For example
tests/early-libtool.at uses them.

Again, this is something we can probably write easily for you (just it
will be until the weekend for me).

 Updated patch attached (two patches from git format-patch, let me know
 if there is a better way to send this).

You can just merge them to one, for example with:
  git rebase -i HEAD~2

which will open a file in an editor.  Replace the edit in the second
line with squash, save, exit, edit the combined log entry.

If you have changes in your tree to tack onto the most recent commit,
you can use 'git commit -a --amend'.

Both strategies assume that the amended-to commits are not published in
a public git repository yet (i.e., nobody has code that depends on them
exactly).

But we can do this kind of fixup too.

Thanks,
Ralf

Re: PATCH RFA: Add Go support

2010-10-13 Thread Ian Lance Taylor 
Ralf Wildenhues ralf.wildenh...@gmx.de writes:

 * Ian Lance Taylor wrote on Wed, Oct 13, 2010 at 07:31:04PM CEST:
 Ralf Wildenhues writes:
  Do you have, or are working on, an Automake patch for Go support?
 
 I do not have an automake patch, although that is a logical next step.
 I've been using libtool with a Makefile.am which uses this definition:
 
 LTGOCOMPILE = $(LIBTOOL) --tag GO --mode=compile $(GCCGO) $(INCLUDES) \
  $(AM_GOFLAGS) $(GOFLAGS)
 
 and then runs $(LTGOCOMPILE) as needed.  Adding Go support to automake
 may be a little tricky as Go requires a slightly different compilation
 model: you must pass all files that are in the same package to the
 compiler at once.  You can't compile them separately.

 That is not a big problem per se.  However, how would you implement
 build parallelism?  Inside gccgo?  Should it eventually have jobserver
 support, received from make?

Note that when I say a package I don't mean an entire program.  A
package in Go is like a single library, or what some languages call a
module.  E.g., the standard Go library has a fmt package, an os package,
a math package, etc.  When compiling Go, you must pass all files in a
package to the compiler at the same time.  In principle part of the
compilation of a single package could be parallelized, but not in any
simple or straightforward way.  You can group many different Go packages
together into a single .a or .so file.

 What if files reside in subdirs (of the current directory, or of
 $srcdir), will objects be created in subdirs or in the current directory
 (and how would we avoid creation of files below $srcdir in a VPATH
 build, given that $srcdir is a concept not known to the compiler a
 priori)?  Or maybe it has no objects at all?

Only one object file is created for each package.  It can go wherever.

 Can the user split up large projects into multiple pieces, either by
 separate Makefile.am files for separate directories, or somehow
 separately compiling the set of sources in one directory, maybe by
 library or by program compiled?

Sure.

 If the latter is to be supported, then
 things like overlapping sources become a problem (i.e., both libfoo and
 libbar use baz.o).

That can not happen, because baz.go can only be in one package.

Ian

PATCH RFA: Add Go support

2010-10-12 Thread Ian Lance Taylor 
This patch adds support for the Go programming language to libtool.  Go
is described at http://golang.org/ .

I'm not very familiar with libtool.  This patch is mostly a
cut-and-paste job.  It is enough to let me use automake with LIBTOOL to
build libraries from Go code.

The patch requires a patch which I've proposed for autoconf:

http://lists.gnu.org/archive/html/autoconf-patches/2010-10/msg4.html

I'm not sure how to handle a libtool patch which requires an autoconf
patch.  Perhaps this can not be committed until the next libtool
release.

In any case I would appreciate any comments and any advice as to how to
get this committed to libtool.  Thanks.

Ian

From b4af7daf876a49174e87a76345f4c8f96521702c Mon Sep 17 00:00:00 2001
From: Ian Lance Taylor i...@google.com
Date: Tue, 12 Oct 2010 14:38:49 -0700
Subject: [PATCH] Add Go support.

---
 ChangeLog  |   11 ++
 doc/libtool.texi   |3 +-
 libltdl/config/ltmain.m4sh |2 +-
 libltdl/m4/libtool.m4  |   84 
 4 files changed, 98 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 9caba84..732b2d3 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,14 @@
+2010-10-12  Ian Lance Taylor  i...@google.com
+
+	* libltdl/m4/libtool.m4 (LT_LANG): Add Go.
+	(AC_PROG_GO): Provide.
+	(_LT_SYS_HIDDEN_LIBDEPS): Add Go case.
+	(_LT_LANG_GO_CONFIG): Define.
+	(LT_PROG_GO): Define.
+	* libltdl/config/ltmain.m4sh: Match *.go.
+	* doc/libtool.texi (LT_INIT): Mention Go.
+	(Tags): Mention Go.
+
 2010-10-07  Roumen Petrov  bugtr...@roumenpetrov.info
 
 	Add test case for 69e77671 (cwrapper PATH manipulation order)
diff --git a/doc/libtool.texi b/doc/libtool.texi
index cd5a181..302e6ed 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -2169,7 +2169,7 @@ specifying @option{--with-pic} to @command{configure}.
 @defmac LT_LANG (@var{language})
 Enable @command{libtool} support for the language given if it
 has not yet already been enabled.  Languages accepted are ``C++'',
-``Fortran 77'', ``Java'' and ``Windows Resource''.
+``Fortran 77'', ``Java'', ``Go'', and ``Windows Resource''.
 
 If Autoconf language support macros such as @code{AC_PROG_CXX} are
 used in your @file{configure.ac}, Libtool language support will automatically
@@ -2768,6 +2768,7 @@ correspondence between language names and tags names.
 @item Java @tab GCJ
 @item Fortran 77   @tab F77
 @item Fortran  @tab FC
+...@item Go   @tab GO
 @item Windows Resource @tab RC
 @end multitable
 
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 1078e75..ee09925 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -1270,7 +1270,7 @@ func_mode_compile ()
 *.[cCFSifmso] | \
 *.ada | *.adb | *.ads | *.asm | \
 *.c++ | *.cc | *.ii | *.class | *.cpp | *.cxx | \
-*.[fF][09]? | *.for | *.java | *.obj | *.sx | *.cu | *.cup)
+*.[fF][09]? | *.for | *.java | *.go | *.obj | *.sx | *.cu | *.cup)
   func_xform $libobj
   libobj=$func_xform_result
   ;;
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 967dd38..fac9cc6 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -801,6 +801,7 @@ AC_DEFUN([LT_LANG],
 m4_case([$1],
   [C],			[_LT_LANG(C)],
   [C++],		[_LT_LANG(CXX)],
+  [Go],			[_LT_LANG(GO)],
   [Java],		[_LT_LANG(GCJ)],
   [Fortran 77],		[_LT_LANG(F77)],
   [Fortran],		[_LT_LANG(FC)],
@@ -852,6 +853,10 @@ AC_PROVIDE_IFELSE([AC_PROG_GCJ],
m4_ifdef([LT_PROG_GCJ],
 	[m4_define([LT_PROG_GCJ], defn([LT_PROG_GCJ])[LT_LANG(GCJ)])])])])])
 
+AC_PROVIDE_IFELSE([AC_PROG_GO],
+  [LT_LANG(GO)],
+  [m4_define([AC_PROG_GO], defn([AC_PROG_GO])[LT_LANG(GO)])])
+
 AC_PROVIDE_IFELSE([LT_PROG_RC],
   [LT_LANG(RC)],
   [m4_define([LT_PROG_RC], defn([LT_PROG_RC])[LT_LANG(RC)])])
@@ -6902,6 +6907,11 @@ public class foo {
   }
 };
 _LT_EOF
+], [$1], [GO], [cat  conftest.$ac_ext _LT_EOF
+package foo
+func foo() {
+}
+_LT_EOF
 ])
 
 _lt_libdeps_save_CFLAGS=$CFLAGS
@@ -7423,6 +7433,75 @@ CC=$lt_save_CC
 CFLAGS=$lt_save_CFLAGS
 ])# _LT_LANG_GCJ_CONFIG
 
+# _LT_LANG_GO_CONFIG([TAG])
+# --
+# Ensure that the configuration variables for the GNU Go compiler
+# are suitably defined.  These variables are subsequently used by _LT_CONFIG
+# to write the compiler configuration to `libtool'.
+m4_defun([_LT_LANG_GO_CONFIG],
+[AC_REQUIRE([LT_PROG_GO])dnl
+AC_LANG_SAVE
+
+# Source file extension for Go test sources.
+ac_ext=go
+
+# Object file extension for compiled Go test sources.
+objext=o
+_LT_TAGVAR(objext, $1)=$objext
+
+# Code to be used in simple compile tests
+lt_simple_compile_test_code=package main; func main() { }
+
+# Code to be used in simple link tests
+lt_simple_link_test_code='package main; func main() { }'
+
+# ltmain only uses $CC for tagged configurations so make sure $CC is set.
+_LT_TAG_COMPILER
+
+# save warnings/boilerplate of simple test code
+_LT_COMPILER_BOILERPLATE

Re: PATCH RFA: Add Go support

2010-10-12 Thread Ralf Wildenhues 
Hello Ian,

thanks for the patch!

* Ian Lance Taylor wrote on Tue, Oct 12, 2010 at 11:42:56PM CEST:
 This patch adds support for the Go programming language to libtool.  Go
 is described at http://golang.org/ .
 
 I'm not very familiar with libtool.  This patch is mostly a
 cut-and-paste job.  It is enough to let me use automake with LIBTOOL to
 build libraries from Go code.

Do you have, or are working on, an Automake patch for Go support?

 The patch requires a patch which I've proposed for autoconf:
 
 http://lists.gnu.org/archive/html/autoconf-patches/2010-10/msg4.html
 
 I'm not sure how to handle a libtool patch which requires an autoconf
 patch.  Perhaps this can not be committed until the next libtool
 release.

We usually try to support older Autoconf as well (currently back to
2.59), so that people don't need to upgrade all at once.  When only
macros from Autoconf proper are missing (as opposed to macros from other
third parties), they can be treated similarly to how AC_PROG_SED is
treated with a backup in libtool.m4.

There might be an ordering issue between the definition of AC_PROG_GO
and the AC_PROVIDE_IFELSE([AC_PROG_GO], ...) because the latter
essentially tacks code onto the former (this might be moot as a define
vs. expand thing, haven't checked though).

 In any case I would appreciate any comments and any advice as to how to
 get this committed to libtool.  Thanks.

tests/suffix.test should be updated.

Can you send output of
  ./libtool --tag=GO --config

for Libtool with Go support enabled?  You need to patch Libtool's
configure.ac to enable Go support (this should be part of the patch as
well).

A NEWS entry would be good.  Testsuite additions (to the new testsuite)
would be nice, like one setup where Go is the only language enabled (to
verify that object and executable extension computation work etc).
We can write those tests if you're not familiar with Autotest.

I haven't checked things in detail yet, but since it is new
functionality, the chance for regression is not so high.

Thanks,
Ralf