[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PATCH RFA: Add Go support

From: Ian Lance Taylor
Subject: Re: PATCH RFA: Add Go support
Date: Mon, 01 Nov 2010 15:14:27 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Ralf Wildenhues <address@hidden> writes:

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

Ah, I see.  Yes, it would not make sense to do this for Go.

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

It could be either way.  If there is only the one object, it might as
well just be a .o file.

>> >> > 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?
>> >
>> > foo_lo_SOURCES += baz.go
>> > else
>> > 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 ...

It's normal to have a single package which had conditionally included
source files.  But what you are describing seems to be the case of the
same source file going into two different packages.  I don't know why
that would ever be useful or interesting.  But, yes, it could be done,
if both of the two different packages used the same name at the source
code level.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]