This is the mail archive of the
mailing list for the GCC project.
Re: Discussion about merging Go frontend
- From: Ian Lance Taylor <iant at google dot com>
- To: Dave Korn <dave dot korn dot cygwin at gmail dot com>
- Cc: gcc-patches at gcc dot gnu dot org, ccoutant at google dot com
- Date: Tue, 02 Nov 2010 15:30:00 -0700
- Subject: Re: Discussion about merging Go frontend
- References: <firstname.lastname@example.org> <4CC45302.email@example.com> <firstname.lastname@example.org> <4CC59F1E.email@example.com> <firstname.lastname@example.org> <AANLkTikEy7ER+CkQdWo0XHPoBORvbp8JZ226QFM68PZv@mail.gmail.com> <email@example.com> <4CC60C5E.firstname.lastname@example.org> <email@example.com> <4CCBF722.firstname.lastname@example.org> <email@example.com> <4CD09461.firstname.lastname@example.org>
Dave Korn <email@example.com> writes:
> On 02/11/2010 15:06, Ian Lance Taylor wrote:
>> It would seem more natural to use AC_DEFINE here. Any reason not to do
> It seems a bit much overkill. There's only a single -D right now, so why
> not pass it straight through? With AC_DEFINE I'd still have to import @DEFS@
> into the makefile, just to get HAVE_CONFIG_H available at build time, and then
> add a config.h with a single #define in it. If there were several symbols to
> define, or if there was already an AC_CONFIG_HEADER, I'd do it, but there
> isn't yet, so why haul all that extra weight?
Because we will almost inevitably want it eventually? I often agree
with that kind of argument, but in this case I lean more toward "start
as you plan to proceed."
>> And of course this code now has to use simple_object rather than
> Yep, I'm just revising it now. Will spin those fixes in at the same time,
> thanks for reviewing. Let me know if you really want to insist on the
> AC_DEFINE change, but if it's up to me I'd rather just leave it as it is.
I've CC'ed the official lto-plugin maintainer, Cary Coutant, to make the