Re: PATCH RFA: Add Go support

[Ralf Wildenhues]

Hello Ian,

let's move this part of the discussion to the automake@ list.
And sorry for delays, I cannot help that ATM.

* Ian Lance Taylor wrote on Wed, Oct 13, 2010 at 09:58:49PM CEST:
> Ralf Wildenhues 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.

OK.  So IIUC one example dependency graph would be something like this:

  ( sin.go cos.go exp.go ) -> math.OBJEXT     -> libfem.so
  ( grid.go solver.go )    -> sub/pdesolve.OBJEXT ---^

where the sets of .go files are distinct, the sets of object files
("packages") cannot be derived from their inputs (neither their names
nor their contents?) but rather specified only in the makefile, and
objects are subsumed in (static or shared) libraries or in programs
as usual.  OBJEXT may be o or obj (for w32) or lo (for libtool).

We need a bit of new notation for this, and we need to teach automake
about languages that shouldn't have renamed objects even in the presence
of per-object flags.

With libtool, naming wouldn't sound so hard, one could just go with
something like:

lib_LTLIBRARIES = libfem.la
libfem_la_LIBADD = math.lo sub/pdesolve.lo  # yes, _LIBADD
math_lo_SOURCES = sin.go cos.go exp.go
sub_pdesolve_lo_SOURCES = grid.go solver.go

Without libtool, we could canonify $(OBJEXT) as _o:

bin_PROGRAMS = fem
fem_LDADD = math.$(OBJEXT) sub/pdesolve.$(OBJEXT)
math_o_SOURCES = sin.go cos.go exp.go
sub_pdesolve_o_SOURCES = grid.go solver.go

but that looks fairly ugly to me already.  Better ideas?

I'm sure users will ask to generalize the scheme for other languages,
where Automake operates differently now.  I'm not yet sure whether that
is a reason to worry or a good thing.  ;-)


> > 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.

Should a package be an installable entity?  At that point we should
think about using a separate new _PRIMARY for it.

> > 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.

Setups like the following are not possible in theory?

if WANT_FEATURE_IN_FOO
foo_lo_SOURCES += baz.go
else
if WANT_FEATURE_IN_BAR
bar_lo_SOURCES += baz.go
endif
endif

Thanks,
Ralf