code review 5756047: cmd/go: add -compiler

cmd/go: add -compiler
go/build: add Context.Compiler

Fixes issue 3157.

[rsc, 2012-03-06 04:13:12]

Hello golang-dev@googlegroups.com,

I'd like you to review this change to
https://code.google.com/p/go/

[r, 2012-03-06 04:27:00]

LGTM

http://codereview.appspot.com/5756047/diff/4001/src/pkg/go/build/build.go
File src/pkg/go/build/build.go (right):

http://codereview.appspot.com/5756047/diff/4001/src/pkg/go/build/build.go#new...
src/pkg/go/build/build.go:346: }
default: errorf

[rsc, 2012-03-06 05:36:27]

*** Submitted as dfb32d4dcab2 ***

cmd/go: add -compiler
go/build: add Context.Compiler

Fixes issue 3157.

R=golang-dev, r
CC=golang-dev
http://codereview.appspot.com/5756047

[albert.strasheim, 2012-03-06 05:49:22]

Hello 

On 2012/03/06 05:36:27, rsc wrote:
> *** Submitted as dfb32d4dcab2 ***
> cmd/go: add -compiler
> go/build: add Context.Compiler

Given this change, does it still make sense to have gccgoflags in addition to
gcflags and ldflags? I can't think of any right now, but maybe there are flags
that should be passed to gccgo when compiling, but not linking?

Regards

Albert

[minux1, 2012-03-06 15:10:53]

On Tue, Mar 6, 2012 at 1:49 PM, <fullung@gmail.com> wrote:
>
>  On 2012/03/06 05:36:27, rsc wrote:
>
>> *** Submitted as dfb32d4dcab2 ***
>> cmd/go: add -compiler
>> go/build: add Context.Compiler
>>
>
> Given this change, does it still make sense to have gccgoflags in
> addition to gcflags and ldflags? I can't think of any right now, but
> maybe there are flags that should be passed to gccgo when compiling, but
> not linking?
>
Merging these flags only make sense if the -compiler flag is always
present, if
it is not, the -gcflags will be ambiguous.

[albert.strasheim, 2012-03-06 15:17:52]

Hello

On Tue, Mar 6, 2012 at 5:10 PM, minux <minux.ma@gmail.com> wrote:
> On Tue, Mar 6, 2012 at 1:49 PM, <fullung@gmail.com> wrote:
>> On 2012/03/06 05:36:27, rsc wrote:
>>> *** Submitted as dfb32d4dcab2 ***
>>> cmd/go: add -compiler
>>> go/build: add Context.Compiler
>> Given this change, does it still make sense to have gccgoflags in
>> addition to gcflags and ldflags? I can't think of any right now, but
>> maybe there are flags that should be passed to gccgo when compiling, but
>> not linking?
> Merging these flags only make sense if the -compiler flag is always present,
> if it is not, the -gcflags will be ambiguous.

I'm not quite sure I understand.

If no compiler flag is present, -gcflags and -ldflags refer to
runtime.Compiler (whatever the default is, according to the tool).

If -compiler is present, they refer to that compiler.

Future worries:

What's going to happen when the 3rd and 4th Go compiler show up on
other platforms like .NET or something on top of LLVM?

What's going to happen when there are multiple versions of gccgo
(e.g., 4.x and 5.x)? Fedora ships multiple compat-gcc-* packages for
older versions of gcc.

Regards

Albert

[minux1, 2012-03-06 15:47:18]

On Tue, Mar 6, 2012 at 11:17 PM, Albert Strasheim <fullung@gmail.com> wrote:

> On Tue, Mar 6, 2012 at 5:10 PM, minux <minux.ma@gmail.com> wrote:
> >> Given this change, does it still make sense to have gccgoflags in
> >> addition to gcflags and ldflags? I can't think of any right now, but
> >> maybe there are flags that should be passed to gccgo when compiling, but
> >> not linking?
> > Merging these flags only make sense if the -compiler flag is always
> present,
> > if it is not, the -gcflags will be ambiguous.
>
> I'm not quite sure I understand.
>
> If no compiler flag is present, -gcflags and -ldflags refer to
> runtime.Compiler (whatever the default is, according to the tool).
>
Oh, I suppose the -gcflags and -ldflags should always refer to [568]g and
[568]l even
if -compiler is provided.
If it is not the case after runtime.Compiler is introduced, then it is a
issue and should
be addressed one way or the other.

>
> If -compiler is present, they refer to that compiler.
>
> Future worries:
>
> What's going to happen when the 3rd and 4th Go compiler show up on
> other platforms like .NET or something on top of LLVM?
>
> What's going to happen when there are multiple versions of gccgo
> (e.g., 4.x and 5.x)? Fedora ships multiple compat-gcc-* packages for
> older versions of gcc.
>
These worries could be addressed later, I think.

[rsc, 2012-03-06 18:49:05]

On Tue, Mar 6, 2012 at 00:49,  <fullung@gmail.com> wrote:
> Given this change, does it still make sense to have gccgoflags in
> addition to gcflags and ldflags? I can't think of any right now, but
> maybe there are flags that should be passed to gccgo when compiling, but
> not linking?

They are for different compilers.
gcflags is for 6g
ldflags is for 6l
gccgoflags is for gccgo
(and it can use -Wl,-foo for link-only flags).

I think it's a feature that you can't accidentally give flags intended for
one compiler to the other.

Russ