This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Discussion about merging Go frontend
Hello,
* Joseph S. Myers wrote on Sat, Nov 06, 2010 at 11:41:17PM CET:
> On Wed, 3 Nov 2010, Ian Lance Taylor wrote:
>
> > There is also the libgo directory. The contents of libgo/go are a copy
> > of the standard Go library and I don't think a review of that would be
> > useful. But it would be reasonable to review the contents of libgo
> > outside of libgo/go. This code can found on the gccgo branch in the
> > libgo subdirectory.
>
> I don't propose to review this. A build-system maintainer might be most
> useful there.
I casually looked at libgo/{Makefile.am,configure.ac}.
You don't need to list .c files in the BUILT_SOURCES variable if they
are also listed in some <prog>_SOURCES variable (and are not
undocumented prerequisites for other targets). make will know that it
needs to create these files. (Omitting BUILT_SOURCES saves a recursive
make invocation in practice.)
> if LIBGO_IS_386
> GOARCH = 386
> else
> if LIBGO_IS_X86_64
> GOARCH = amd64
> else
> if LIBGO_IS_ARM
> GOARCH = arm
> else
> GOARCH = unknown
> endif
> endif
> endif
I wouldn't write Automake conditionals deeply nested, it makes for long
lines and quadratic number of characters in Makefile.in when the number
of conditionals increases. But who am I telling that. ;-)
You could just AC_SUBST([GOARCH]) and GOOS from configure.ac; but this
is a really minor stylistic issue.
Several %/check targets use 'mkdir -p'. While that is quite portable
nowadays, there are still mkdir implementations that are racy when run
in parallel. You can use $(MKDIR_P) instead.
I suppose portability to systems where OBJEXT is .obj is not a question
at this point.
configure.ac didn't really show up much at a glance.
Cheers,
Ralf