autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PATCH RFA: Add support for Go programming language


From: Ralf Wildenhues
Subject: Re: PATCH RFA: Add support for Go programming language
Date: Tue, 12 Oct 2010 22:52:18 +0200
User-agent: Mutt/1.5.20 (2010-08-04)

Hi Ian,

* Ian Lance Taylor wrote on Tue, Oct 12, 2010 at 09:37:40PM CEST:
> This patch adds support for the Go programming language to autoconf.
> The Go programming language is described at http://golang.org/ .
> 
> This is fairly basic support.  It only works with gccgo, the Go frontend
> to gcc.  It has no special features.  However, it is enough to write
> AC_PROG_GO and have the GCCGO and GOFLAGS variables set for use in a
> Makefile.
> 
> Please let me know what steps I should take to get this into the
> mainline of autoconf.  Thanks.

Thanks for the patch.  I'll leave approval to Eric, and just note a
couple of nits/questions below.

Cheers,
Ralf

> --- a/doc/autoconf.texi
> +++ b/doc/autoconf.texi
> @@ -341,7 +341,7 @@ Top
>  
>  * Preset Output Variables::     Output variables that are always set
>  * Installation Directory Variables::  Other preset output variables
> -* Changed Directory Variables:: Warnings about @file{datarootdir}
> +* Changed Directory Variables::  Warnings about @file{datarootdir}

Did you do the menu rebuilding automatically?  If yes, how?

>  * Build Directories::           Supporting multiple concurrent compiles
>  * Automatic Remaking::          Makefile rules for configuring
>  

> @@ -8207,6 +8224,32 @@ Fortran Compiler
>  @end defmac
>  
>  
> address@hidden Go Compiler
> address@hidden Go Compiler Characteristics
> address@hidden Go
> +
> +Autoconf provides basic support for the Go programming language when
> +using the @code{gccgo} compiler (there is currently no support for the
> address@hidden and @code{8g} compilers).
> +
> address@hidden AC_PROG_GO (@ovar{compiler-search-list})
> +Find the Go compiler to use.  Check whether the environment variable
> address@hidden is set; if so, then set output variable @code{GCCGO} to its
> +value.

Why name the variable GCCGO?  In line with other compiler variables
would be something like GOC (for GO Compiler) or GOCC, that would also
match with GOFLAGS.  Do you expect this interface to never apply to
non-GCC implementations of Go?

> +Otherwise, if the macro is invoked without an argument, then search for
> +a Go compiler named @code{gccgo}.  If it is not found, then as a last
> +resort set @code{GCCGO} to @code{gccgo}.
> +
> +This macro may be invoked with an optional first argument which, if
> +specified, must be a blank-separated list of Go compilers to search for.
> +
> +If output variable @code{GOFLAGS} was not already set, set it to
> address@hidden -O2}.  If your package does not like this default,
> address@hidden may be set before @code{AC_PROG_GO}.
> address@hidden defmac
> +
> +
>  @node System Services
>  @section System Services

> --- /dev/null
> +++ b/lib/autoconf/go.m4

> +# AC_LANG_INT_SAVE(Go)(PROLOGUE, EXPRESSION)
> +# ------------------------------------------
> +m4_define([AC_LANG_INT_SAVE(Go)],
> +[AC_LANG_PROGRAM([$1
> +import (
> +     "fmt"
> +     "os"
> +)
> +],
> +[f, err := os.Open("conftest.val", os.O_CREATE|os.O_WRONLY, 0777)

Does Go require no space before open parentheses, or is it conventional
to not follow GCS spacing in Go?

> + if err != nil {
> +     os.Exit(1)
> + }
> + if $2 < 0 {
> +     int64 i = int64($2)
> +     if i != $2 {
> +             os.Exit(1)
> +     }
> +     if _, err := fmt.Print(f, i); err != nil {
> +             os.Exit(1)
> +     }
> + } else {
> +     uint64 i = uint64($2)
> +     if i != $2 {
> +             os.Exit(1)
> +     }
> +     if _, err := fmt.Print(f, i); err != nil {
> +             os.Exit(1)
> +     }
> + }
> + if err = f.Close(); err != nil {
> +     os.Exit(1)
> + }
> + os.Exit(0);
> +])])
> +
> +# ---------------------- #
> +# Looking for compilers. #
> +# ---------------------- #
> +
> +# AC_LANG_COMPILER(Go)
> +# --------------------
> +AC_DEFUN([AC_LANG_COMPILER(Go)],
> +[AC_REQUIRE([AC_PROG_GO])])
> +
> +# AC_PROG_GO
> +# ----------
> +AN_MAKEVAR([GCCGO], [AC_PROG_GO])
> +AN_PROGRAM([gccgo], [AC_PROG_GO])
> +AC_DEFUN([AC_PROG_GO],
> +[AC_LANG_PUSH(Go)dnl
> +AC_ARG_VAR([GCCGO],   [Go compiler command])dnl
> +AC_ARG_VAR([GOFLAGS], [Go compiler flags])dnl
> +_AC_ARG_VAR_LDFLAGS()dnl
> +m4_ifval([$1],
> +      [AC_CHECK_TOOLS(GCCGO, [$1])],
> +[AC_CHECK_TOOL(GCCGO, gccgo)
> +if test -z "$GCCGO"; then
> +  if test -n "$ac_tool_prefix"; then
> +    AC_CHECK_PROG(GCCGO, [${ac_tool_prefix}gccgo], [$ac_tool_prefix}gccgo])
> +  fi
> +fi
> +if test -z "$GCCGO"; then
> +  AC_CHECK_PROG(GCCGO, gccgo, gccgo, , , gccgo)

The sixth argument to AC_CHECK_PROG doesn't make sense to me.  It should
name an absolute file name that would always be rejected, but 'gccgo' is
not absolute.  OTOH, the fourth VALUE-IF-NOT-FOUND argument is empty,
which is probably not very helpful either.  I'd prefer 'false', so
compile rules are guaranteed to fail; notwithstanding the practice to
not do so in other AC_PROG_* macros.

> +fi
> +])
> +
> +# Provide some information about the compiler.
> +_AS_ECHO_LOG([checking for _AC_LANG compiler version])
> +set X $ac_compile
> +ac_compiler=$[2]
> +_AC_DO_LIMIT([$ac_compiler --version >&AS_MESSAGE_LOG_FD])
> +m4_expand_once([_AC_COMPILER_EXEEXT])[]dnl
> +m4_expand_once([_AC_COMPILER_OBJEXT])[]dnl
> +GOFLAGS="-g -O2"
> +AC_LANG_POP(Go)dnl
> +])# AC_PROG_GO

> diff --git a/tests/go.at b/tests/go.at
> new file mode 100644
> index 0000000..9ed5430
> --- /dev/null
> +++ b/tests/go.at

> +# Since the macros which compile are required by most tests, check
> +# them first.  But remember that looking for a compiler is even more
> +# primitive, so check those first.
> +
> +
> +## ------------- ##
> +## Go Compiler.  ##
> +## ------------- ##
> +
> +AT_CHECK_MACRO([Go],
> +[[AC_LANG(Go)
> +AC_LANG_COMPILER
> +]])

Just for reference, can you post the output of
  make check TESTSUITEFLAGS='-k go -v -x'

with a Go compiler in $PATH?

Thanks,
Ralf



reply via email to

[Prev in Thread] Current Thread [Next in Thread]