Re: PATCH RFA: Add Go support

[Ralf Wildenhues]

[ dropping libtool@ ]

* Ian Lance Taylor wrote on Mon, Nov 01, 2010 at 09:48:03PM CET:
> Ralf Wildenhues <address@hidden> writes:
> 
> > 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.
> 
> Hmmm, no, the objects can be renamed.  The agreement between source
> level package name and file level package name is by convention only.

Misunderstanding; sorry.  What I meant was that automake shouldn't by
itself rename object file names.  It currently does that for example
with setups like

foo_SOURCES = foo.c
bar_SOURCES = foo.c
bar_CPPFLAGS = -Dbar

> >> > 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.
> 
> A package can be installable by itself, sure.

Would that then be in the form of an object, or would you make an
archive out of 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
> 
> Right, that is not possible, unless foo.lo and bar.lo define the same
> package, which would be very odd.

Why?  With system-dependent differences that doesn't seem too remote
(the conditionals don't both have to be true on the same system).
Generally, Automake users will eventually come up with some use case
even for pretty remote cases ...

Cheers,
Ralf