public inbox for goredo-devel@lists.stargrave.org
Atom feed
From: Sergey Matveev <stargrave@stargrave•org>
To: goredo-devel@lists.cypherpunks.su
Subject: Re: Memory exhaustion issues
Date: Thu, 5 Sep 2024 21:49:54 +0300 [thread overview]
Message-ID: <Ztn9X4IQL4Mds-GL@stargrave.org> (raw)
In-Reply-To: <3ed9ebbd49e87a5babd7bf9e5b0984ab@spacefrogg.net>
[-- Attachment #1: Type: text/plain, Size: 1084 bytes --]
Greetings!
*** spacefrogg [2024-08-19 12:12]:
>My suggestion would be that, if in any way possible, redo should try to
>follow the dependency graph in depth-first-order to minimize the number of
>half-executed targets waiting on redo-if* calls.
This is not possible, because, unlike Make, targets that are going to be
built are not known in advance. We just can *assume* what will be built,
according to our previous run, but we can not (have no right) to build
them, if they are not explicitly requested by redo-* command. Each
redo-* invocation literally tells redo to "here, build those targets
too", and those targets also tells redo to build another ones. All of
that are dynamically generated by invokers of redo-* commands. And we
have to wait for their finishing, because as a rule we are inside some
.do file, that will have other commands after redo* calls. Personally I
see no way to change that behaviour somehow. That is the redo's nature.
--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: 12AD 3268 9C66 0D42 6967 FD75 CB82 0563 2107 AD8A
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2024-09-05 18:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-19 10:12 Memory exhaustion issues spacefrogg
2024-09-05 18:49 ` Sergey Matveev [this message]
2024-09-05 19:49 ` goredo
2024-09-08 10:11 ` Sergey Matveev
2024-09-09 10:49 ` spacefrogg
2024-09-10 6:50 ` Sergey Matveev