This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, Darwin] update t-* and x-* fragments after switch to auto-deps.
- From: Iain Sandoe <iain at codesourcery dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Mike Stump <mikestump at comcast dot net>, Tom Tromey <tromey at redhat dot com>
- Date: Sat, 28 Sep 2013 21:48:16 +0100
- Subject: Re: [Patch, Darwin] update t-* and x-* fragments after switch to auto-deps.
- Authentication-results: sourceware.org; auth=none
- References: <5A4296A4-10B6-4C9B-AF0A-1955B4DF40F4 at codesourcery dot com> <Pine dot LNX dot 4 dot 64 dot 1309281637290 dot 20127 at digraph dot polyomino dot org dot uk> <9546E761-6417-44AC-84AF-A2C6624F8749 at codesourcery dot com>
Hello Joseph,
On 28 Sep 2013, at 17:44, Iain Sandoe wrote:
> On 28 Sep 2013, at 17:40, Joseph S. Myers wrote:
>
>> On Sat, 28 Sep 2013, Iain Sandoe wrote:
>>
>>> * config/t-darwin (darwin.o, darwin-c.o, darwin-f.o, darwin-driver.o):
>>> Use COMPILE and POSTCOMPILE.
>>> * config/x-darwin (host-darwin.o): Likewise.
>>> * config/i386/x-darwin (host-i386-darwin.o): Likewise.
>>> * config/rs6000/x-darwin (host-ppc-darwin.o): Likewise.
>>> * config/rs6000/x-darwin64 (host-ppc64-darwin.o): Likewise.
>>
>> Do you need these compilation rules at all? Or could you change
>> config.host to use paths such as config/host-darwin.o rather than just
>> host-darwin.o, and so allow the generic rules to be used (my understanding
>> was that the auto-deps patch series made lots of such changes to the
>> locations of .o files in the build tree to avoid needing special
>> compilation rules for particular files)?
>
> Good id, I'll investigate this.
I had a look at this, and it seems like a useful objective. However, unless I'm missing a step, [following the template of config.gcc:out_file] it seem to require a fair amount of modification (introduction of common-object placeholders etc. in the configury and Makefile.in) - plus application and testing of this on multiple targets. Not something I can realistically volunteer to do in the immediate future.
Therefore, I'm going to suggest keeping this patch 'as is' and following up later, when there is more time available, with a patch for the other modification.
Iain