[v3,12/18] convert the Go front end to automatic dependencies

This converts Go.

It renames gospec.o to go/gospec.o, for uniformity and so we can
remove an explicit rule.

It defines go_OBJS, to conform to the documented Make-lang.in
conventions, and to ensure that Go objects are given the correct
order-only dependencies on generated files.

	* Make-lang.in (gospec.o): Remove.
	(CFLAGS-go/gospec.o): New variable.
	(GCCGO_OBJS): Update to use go/gospec.o.
	(go_OBJS): Define.
	(GO_SYSTEM_H, GO_C_H, GO_LINEMAP_H, GO_LEX_H, GO_PARSE_H)
	(GO_GOGO_H, GO_TYPES_H, GO_STATEMENTS_H, GO_EXPRESSIONS_H)
	(GO_EXPORT_H, GO_IMPORT_H, GO_RUNTIME_H, GO_AST_DUMP_H)
	(go/go-backend.o, go/go-lang.o, go/go-gcc.o, go/go-linemap.o)
	(go/ast-dump.o, go/dataflow.o, go/export.o, go/expressions.o)
	(go/go.o, go/go-dump.o, go/go-optimize.o, go/gogo-tree.o)
	(go/gogo.o, go/import.o, go/import-archive.o, go/lex.o)
	(go/parse.o, go/runtime.o, go/statements.o, go/types.o)
	(go/unsafe.o): Remove.
	(CFLAGS-go/go-gcc.o, CFLAGS-go/go-linemap.o): New variables.
	(go/%.o: go/gofrontend/%.cc): Use COMPILE and POSTCOMPILE.
---
 gcc/go/Make-lang.in | 99 +++++------------------------------------------------
 1 file changed, 8 insertions(+), 91 deletions(-)

2013/8/20 Tom Tromey <tromey@redhat.com>:
> This converts Go.
>
> It renames gospec.o to go/gospec.o, for uniformity and so we can
> remove an explicit rule.
>
> It defines go_OBJS, to conform to the documented Make-lang.in
> conventions, and to ensure that Go objects are given the correct
> order-only dependencies on generated files.
>
>         * Make-lang.in (gospec.o): Remove.
>         (CFLAGS-go/gospec.o): New variable.
>         (GCCGO_OBJS): Update to use go/gospec.o.
>         (go_OBJS): Define.
>         (GO_SYSTEM_H, GO_C_H, GO_LINEMAP_H, GO_LEX_H, GO_PARSE_H)
>         (GO_GOGO_H, GO_TYPES_H, GO_STATEMENTS_H, GO_EXPRESSIONS_H)
>         (GO_EXPORT_H, GO_IMPORT_H, GO_RUNTIME_H, GO_AST_DUMP_H)
>         (go/go-backend.o, go/go-lang.o, go/go-gcc.o, go/go-linemap.o)
>         (go/ast-dump.o, go/dataflow.o, go/export.o, go/expressions.o)
>         (go/go.o, go/go-dump.o, go/go-optimize.o, go/gogo-tree.o)
>         (go/gogo.o, go/import.o, go/import-archive.o, go/lex.o)
>         (go/parse.o, go/runtime.o, go/statements.o, go/types.o)
>         (go/unsafe.o): Remove.
>         (CFLAGS-go/go-gcc.o, CFLAGS-go/go-linemap.o): New variables.
>         (go/%.o: go/gofrontend/%.cc): Use COMPILE and POSTCOMPILE.

This is OK.

I assume that dropping $(OUTPUT_OPTION) is correct--I haven't looked
at the new definition of $(COMPILE).

Many thanks.

Ian

>>>>> "Ian" == Ian Lance Taylor <iant@google.com> writes:

Ian> I assume that dropping $(OUTPUT_OPTION) is correct--I haven't looked
Ian> at the new definition of $(COMPILE).

I believe the depcomp script takes care of this.

Tom

Il 26/08/2013 18:09, Tom Tromey ha scritto:
>>>>>> "Ian" == Ian Lance Taylor <iant@google.com> writes:
> 
> Ian> I assume that dropping $(OUTPUT_OPTION) is correct--I haven't looked
> Ian> at the new definition of $(COMPILE).
> 
> I believe the depcomp script takes care of this.

I think that would be the "compile" script, not depcomp.  But I suspect
that this has been broken for a while, since the C front-end require
$(OUTPUT_OPTION).

You are listed as the author of the "compile" script in Automake, do you
remember which compilers need it?  I'm too young for that (that's
something I can say less and less :))...

Paolo

Paolo> You are listed as the author of the "compile" script in Automake, do you
Paolo> remember which compilers need it?  I'm too young for that (that's
Paolo> something I can say less and less :))...

I have no idea any more.

I can try a test build using a setting for CC that rejects -c -o.

Tom

Tom> I can try a test build using a setting for CC that rejects -c -o.

I did this and the build died pretty early on:

  /home/tromey/Space/Trunk/Git/bin/my-cc -c -DHAVE_CONFIG_H -g -g -I. -I../../gcc/libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  -fpic ../../gcc/libiberty/regex.c -o pic/regex.o; \
else true; fi
no -c -o support
make[3]: *** [regex.o] Error 1
make[3]: Leaving directory `/home/tromey/Space/Trunk/Git/build/libiberty'
make[2]: *** [all-stage1-libiberty] Error 2


In this case the --enable-shared for libiberty was added automatically
because LTO defaults to enabled.  Adding --disable-lto lets it get
further:

/home/tromey/Space/Trunk/Git/bin/my-cc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"zlib\" -DVERSION=\"1.1.4\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_STDLIB_H=1 -DHAVE_UNISTD_H=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DHAVE_MEMCPY=1 -DHAVE_STRERROR=1 -DHAVE_UNISTD_H=1 -I. -I../../gcc/zlib   -g  -g -c -o libz_a-adler32.o `test -f 'adler32.c' || echo '../../gcc/zlib/'`adler32.c
no -c -o support
make[3]: *** [libz_a-adler32.o] Error 1
make[3]: Leaving directory `/home/tromey/Space/Trunk/Git/build/zlib'
make[2]: *** [all-stage1-zlib] Error 2


And indeed, zlib's configure.ac does not invoke AC_PROG_CC_C_O.

So, maybe this has been broken a long time.

Tom

Il 16/09/2013 19:23, Tom Tromey ha scritto:
> Tom> I can try a test build using a setting for CC that rejects -c -o.
> 
> I did this and the build died pretty early on:
> 
>   /home/tromey/Space/Trunk/Git/bin/my-cc -c -DHAVE_CONFIG_H -g -g -I. -I../../gcc/libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  -fpic ../../gcc/libiberty/regex.c -o pic/regex.o; \
> else true; fi
> no -c -o support
> make[3]: *** [regex.o] Error 1
> make[3]: Leaving directory `/home/tromey/Space/Trunk/Git/build/libiberty'
> make[2]: *** [all-stage1-libiberty] Error 2
> 
> 
> In this case the --enable-shared for libiberty was added automatically
> because LTO defaults to enabled.  Adding --disable-lto lets it get
> further:
> 
> /home/tromey/Space/Trunk/Git/bin/my-cc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"zlib\" -DVERSION=\"1.1.4\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_STDLIB_H=1 -DHAVE_UNISTD_H=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DHAVE_MEMCPY=1 -DHAVE_STRERROR=1 -DHAVE_UNISTD_H=1 -I. -I../../gcc/zlib   -g  -g -c -o libz_a-adler32.o `test -f 'adler32.c' || echo '../../gcc/zlib/'`adler32.c
> no -c -o support
> make[3]: *** [libz_a-adler32.o] Error 1
> make[3]: Leaving directory `/home/tromey/Space/Trunk/Git/build/zlib'
> make[2]: *** [all-stage1-zlib] Error 2
> 
> 
> And indeed, zlib's configure.ac does not invoke AC_PROG_CC_C_O.
> 
> So, maybe this has been broken a long time.

Likely.  Zapping OUTPUT_OPTION sounds like the right thing to do.

Paolo