This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Avoid invoking ranlib on libbackend.a


On Sun, Jul 17, 2016 at 10:43 AM, Patrick Palka <patrick@parcs.ath.cx> wrote:
> On Sun, Jul 17, 2016 at 9:15 AM, David Edelsohn <dje.gcc@gmail.com> wrote:
>>>>>>> Patrick Palka writes:
>>
>>> Hmm, this is only a problem due to command line length limits right?
>>> Fortunately the change makes the longest command line only about 10%
>>> longer than the previous longest command line.  With the change to
>>> avoid building libbackend.a altogether, the longest command line is
>>> now the cc1plus link command which is 4430 bytes long.  Without this
>>> change, the longest command line is the "ar rc libbackend.a"
>>> invocation at 4095 bytes (from what I can tell).  It's still pretty
>>> far away from the 8k limit imposed by Windows.
>>
>> Windows is not the only non-Linux system on which GCC runs.
>>
>> You repeatedly are making bad assumptions and assertions without
>> having studied much about GCC. You assume that GNU ar is the only
>> archiver in use. You propose removing libbackend.a without having
>> investigated when it was introduced and why.
>>
>> Your patches would be a lot more compelling if you invested the time
>> to learn some context.
>
> The only patch I officially proposed is the one elides the invocation
> of ranlib if the current ar is GNU ar (thanks to those who kindly
> mentioned that other ar's are supported).  Do you have any comments
> about this patch?

Testing for and utilizing a feature of GNU ar that speeds up builds
seems like a nice improvement, but it obviously adds complexity and
increases the risk that an independent change silently will introduce
build problems on some systems.

> And you're right.  I am sorry for suggesting ways to improve rebuild
> times without first uncovering the undocumented intricacies of the
> build system.  Shame on me!

Yes, GCC is a large and intricate Free Software project.  And
contributing patches requires some archaeology to understand the
motivation and reason for the design choices as part of the software
engineering process.  GCC supports and runs on a very large and
diverse set of systems, which is one facet of its strength.

One goal of GCC is evolution toward a more modular design:

https://gcc.gnu.org/wiki/ModularGCC

Thanks, David


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]