Re: PATCH RFA: Add Go support
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 * 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 variables
Re: PATCH RFA: Add Go support
Ralf Wildenhues 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
Hello Ian, let's move this part of the discussion to the automake@ list. And sorry for delays, I cannot help that ATM. * Ian Lance Taylor wrote on Wed, Oct 13, 2010 at 09:58:49PM CEST: > Ralf Wildenhues 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. 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). 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. With libtool, naming wouldn't sound so hard, one could just go with something like: lib_LTLIBRARIES = libfem.la libfem_la_LIBADD = math.lo sub/pdesolve.lo # yes, _LIBADD math_lo_SOURCES = sin.go cos.go exp.go sub_pdesolve_lo_SOURCES = grid.go solver.go Without libtool, we could canonify $(OBJEXT) as _o: bin_PROGRAMS = fem fem_LDADD = math.$(OBJEXT) sub/pdesolve.$(OBJEXT) math_o_SOURCES = sin.go cos.go exp.go sub_pdesolve_o_SOURCES = grid.go solver.go but that looks fairly ugly to me already. Better ideas? I'm sure users will ask to generalize the scheme for other languages, where Automake operates differently now. I'm not yet sure whether that is a reason to worry or a good thing. ;-) > > 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. > > 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 Thanks, Ralf
Re: PATCH RFA: Add Go support
Ralf Wildenhues 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
Re: PATCH RFA: Add Go support
* 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
Ralf Wildenhues 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
Re: PATCH RFA: Add Go support
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
PATCH RFA: Add Go support
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 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 + + * 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 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 +_LT_LINKER_BOILERPLATE + +# Allow CC to be a progr