public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Nuno Silva <nunojsilva@ist.utl.pt>
To: gentoo-user@lists.gentoo.org
Subject: [gentoo-user] Re: Question about compilation
Date: Sun, 09 Feb 2025 00:46:08 +0000	[thread overview]
Message-ID: <vo8tsg$fo6$1@ciao.gmane.io> (raw)
In-Reply-To: 7166e50d-8bab-652d-80fb-bb954bff733a@gmail.com

On 2025-02-09, Dale wrote:

> Michael wrote:
>> On Saturday 8 February 2025 23:07:38 Greenwich Mean Time Jack wrote:
>>> On 2025.02.08 14:00, Filip Kobierski wrote:
>>>> On Saturday, February 8th, 2025 at 15:47,
>>>> Jacques Montier <jmontier@gmail.com> wrote:
>>>>
>>>>> Is it possible to stop a compilation midway in the case of a very
>>>>> long compilation and then resume it from the same point without
>>>>> having to start over from the beginning ?
>>>
>>>> I think you are looking for SIGSTP or SIGSTOP but I think that's
>>>> not exactly it. From what I know you cannot do that for emerge
>>>> easily. For similar results you might want to set up ccache.
>>>> https://wiki.gentoo.org/wiki/Ccache
>>>
>>> If you really mean just interrupting a compile, then you should be able
>>> to stop with Ctl-C, and then start/continue by running make or ninja
>>> again, assuming that is what is used for whatever you are compiling.
>>> Ccache can help since most of the results of the previous compile
>>> attempt will have been cached, and so will be completed more quickly
>>> the next time, but it's not the same as continuing from where it was
>>> interrupted.
>>>
>>> If, as Filip implies, you are asking about interrupting emerge, it's
>>> easy enough to interrupt, but essentially impossible to continue from
>>> where it left off.  "emerge --continue" will just try to emerge every
>>> package from the interrupted emerge which was not completed, but it
>>> will start each one from scratch.  What has often, but not alwasy
>>> worked for me, is to use ebuild directly.  "ebuild
>>> .../path/to/package.ebuild compile" will figure out that everything
>>> prior to the compile was completed, and then issue the make or ninja
>>> commands, which will just pick up where they left off.  If that does
>>> work, then you need to repeat the ebuild, but with the install and then
>>> the qmerge commands.  The only problem with that (for me, at least) is
>>> that ebuild does not leave exactly the same lines in emerge.log, so a
>>> package installed that way will not show up in "gentlop -t package"
>>> output.
>> You can run 'ebuild <package> merge', but this will only continue with the 
>> last package you were emerging when it was interrupted and it will continue 
>> from whatever stage the emerge was at the time it was interrupted.
>>
>> If your intention is to suspend/hibernate the OS halfway through an emerge and 
>> continue later on, then you can suspend the emerge job with job control:
>>
>> Ctrl+z
>>
>> After you wake up the system from suspend or reboot from hibernate you can 
>> bring the emerge job back into the foreground, so it can continue running from 
>> where you left it, by invoking:
>>
>> fg
>>
>> NOTE:  Depending how many threads you were running before you suspended the 
>> emerge and how much swap was being used, you may need to wait for a few 
>> minutes for all the threads to pause.  Keep an eye on top to confirm this has 
>> taken place and the CPU is now idle, before you suspend/hibernate the OS.  If 
>> you don't you could discover the suspend/hibernate fails if you do not have 
>> enough RAM/space.
>
>
> Would that survive a full reboot?  I'm asking about a regular desktop
> top system.  It's rare but sometimes I am doing updates and have a power
> failure and have to shutdown until power comes back.  I've always just
> done a emerge --resume but that starts any unfinished emerges from
> scratch.  Just curious if this would work.  If I can remember to do it
> if it does.  ;-) 
>
> Dale
>
> :-)  :-) 

No, that's shell job control, it will live only while the shell process
lives, so wouldn't survive a shutdown/reboot.

There were one or two FEATUREs that could be used to restart where it
stopped, was it FEATURE="keepwork"? (I guess it's a bit like invoking
the build system or ebuild directly on the partial build as mentioned
upthread, but with the comfort of doing it through emerge.)

-- 
Nuno Silva



  parent reply	other threads:[~2025-02-09  0:47 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-08 14:47 [gentoo-user] Question about compilation Jacques Montier
2025-02-08 19:00 ` Filip Kobierski
2025-02-08 23:07   ` Jack
2025-02-09  0:11     ` Michael
2025-02-09  0:20       ` Dale
2025-02-09  0:23         ` Matt Jolly
2025-02-09  5:28           ` Dale
2025-02-16 17:22             ` Wols Lists
2025-02-16 19:12               ` Dale
2025-02-09  0:46         ` Nuno Silva [this message]
2025-02-09 10:23 ` MLR
2025-02-09 14:36 ` Håkon Alstadheim
2025-02-09 16:44   ` Jacques Montier
2025-02-09 17:06     ` Michael
2025-02-09 17:22       ` Jacques Montier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='vo8tsg$fo6$1@ciao.gmane.io' \
    --to=nunojsilva@ist.utl.pt \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox