[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Gnu make option to fix parallel multiple ar on a shared archive
From: |
Kaz Kylheku |
Subject: |
Re: Gnu make option to fix parallel multiple ar on a shared archive |
Date: |
Mon, 12 Aug 2024 13:26:38 -0700 |
User-agent: |
Roundcube Webmail/1.4.15 |
On 2024-08-11 13:09, Philip Guenther wrote:
> On Sun, Aug 11, 2024 at 11:31 AM Kaz Kylheku <kaz@kylheku.com> wrote:
>> Idea: fix the code generator so that for each rule that updates
>> an archive, it uses a unique name for the archive specific to that
>> rule. Perhaps by using numbers: libfoo.001.a, libfoo.002.a, ...
>>
>> Then, the generator must also emit a new rule like this
>>
>> libfoo.a: libfoo.001.a libfoo.002.a ...
>> ...
>>
>> whose recipe lines combines the smaller archives into the one big one
>> that is then used elsewhere as a dependency.
>
> Hmm, can you expound on the value the libfoo.###.a files provide?
Maybe none. Not having seen the original generator or the makefile it
generates, I'm just going with something that is close to its
paradigm. For some reason, it outputs rules that want to destructively
update a common archive. Redirecting the rules to update smaller,
separate archives instead just sticks more or less with the
same approach.
I don't have an intuition for how these archive-side-effecting
rules/recipes are hooked into the dependency graph. They can't be
using the timestamp of the archive, because that is touched multiple
times.
(If they are just making .o files in the usual way but, oh,
with a side effect of also shunting the dropped .o files into an
archive, that would be quite wrongheaded.)