Re: PATCH RFA: Add Go support

[Ian Lance Taylor]

Ralf Wildenhues <address@hidden> 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