Re: PATCH RFA: Add Go support

[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