Re: PATCH RFA: Add Go support

[Ian Lance Taylor]

Ralf Wildenhues <address@hidden> writes:

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

That is essentially correct.  The source file does include the name of
the package.  E.g., your example, each of sin.go, cos.go, and exp.go
would start with "package math".  There is no necessary connection
between the name used in the source file and the name of the object
file.  But it would certainly be conventional to use the same name for
the package name and the object file name.

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


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

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

Ian