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