bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#30948: [PATCH core-updates] guix: Reap finished child processes in b


From: Maxim Cournoyer
Subject: bug#30948: [PATCH core-updates] guix: Reap finished child processes in build containers.
Date: Mon, 28 Nov 2022 15:10:15 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)

Hi,

Ludovic Courtès <ludo@gnu.org> writes:

> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>
> [...]
>
>>> If I write:
>>>
>>>   (gexp->derivation "foo" #~(mkdir #$output))
>>>
>>> I can be sure that my derivation depends on nothing but (default-guile).
>>> This is important for tests, but also to make sure we can use this
>>> primitive everywhere—if it pulled in the Shepherd, I wouldn’t be able to
>>> use to build glibc, because there’d be a cycle.
>>
>> I was not suggesting to pull in extra dependencies such as Shepherd, but
>> to weave the to-be-added signal handling logic at a much lower level.
>> One idea could be to arrange so that the correct signal handlers always
>> get installed for any Guile code running in the build side (I'm not sure
>> how, but perhaps by adjusting the gexp "compiler"?).
>>
>> The handlers could be defined in (guix build signal-handling) or
>> similar.  Users wouldn't need to explicitly import the module and
>> install its signal handlers, that'd be taken care of automatically, all
>> the time.
>>
>> Does that sound feasible?
>
> Not like this: the imported-modules derivation for (guix build
> signal-handling) would be a dependency in themselves.

Can we make it an implicit dependency, since we want it to *always* be
used?

It'd be useless/annoying boilerplate otherwise.

-- 
Thanks,
Maxim





reply via email to

[Prev in Thread] Current Thread [Next in Thread]