Re: PATCH: Move sysdeps/x86_64/Implies to sysdeps/x86_64/64

["Carlos O'Donell" <carlos at systemhalted dot org>]

On Thu, Mar 22, 2012 at 7:02 PM, David Miller <davem@davemloft.net> wrote:
> From: "Joseph S. Myers" <joseph@codesourcery.com>
> Date: Thu, 22 Mar 2012 22:28:53 +0000 (UTC)
>
>> On Thu, 22 Mar 2012, Roland McGrath wrote:
>>
>>> I definitely want other people to give opinions about this before we decide
>>> what to do.
>>
>> I find the finer points of Implies ordering rather confusing, but one
>> thing that would be in favour of any enhancement to the scheme would be if
>> it avoids the need for such files as
>> sysdeps/unix/sysv/linux/powerpc/powerpc32/power7/Implies (which says
>>
>> powerpc/powerpc32/power7/fpu
>> powerpc/powerpc32/power7
>>
>> ) - I'm not sure exactly what ordering issue that is addressing, but it
>> would be good to have a clear explanation for both that and the present
>> x32 issue (actually saying what the salient difference is between two
>> orderings, and what files that difference matters for).
>
> All of those things are probably dealing with the same issue Sparc has
> to contend with, which is that if you need compat routines built for
> an earlier ABI where "long double" == "double" then you have to play
> games to get the cpu sysdep directories in the sysdep list before
> ldbl-opt.
>
> As an aside, if I spent a few months reworking glibc's build system
> such that it didn't generate thousands of prefix rules every directory
> traversal (and thus result in combinatorial explosion inside of GNU
> make) how receptive would people be to this?
>
> It just really irks me that more than %60 of my build time is spent
> processing rules inside of GNU Make, rather than compiling or running
> test cases.

I would be very receptive, but it's not going to be an easy job.

I don't want to see a giant rewrite without at least an attempt
at an incremental makeover.

There have been patches in the past (Jakub?) to reduce the size
of the generated rules.

Cheers,
Carlos.