Re: SCONS -j12, console output is disordered

Bill Deegan <[email protected]> Sat, 23 Dec 2023 12:47:12 -0800
Newsgroups gmane.comp.programming.tools.scons.user
Message-ID <CAEyG4CFOGLRwYbsfb4+vZc9-EqhmZHF-4inok1Tj1wo7bUwn=g@mail.gmail.com>
It's been done before by some users. Not sure if they've shared.
You could probably roll your own if you set env['SPAWN'] and had it hold a
lock or something while dumping the process output.

PRs welcome..

On Sat, Dec 23, 2023 at 11:29 AM Mats Wichmann <[email protected]> wrote:

> On 12/23/23 11:33, Duane Ellis wrote:
> > SCONS could –
> >
> >                  Capture the output of each sub process in the standard
> way.
> >
> >                  Ie: use “POPEN()” and COMMUNICATE with the sub process.
> >
> >                     Thus the subprocess output goes to SCONS and SCONS
> > collects it in a buffer.
>
> Yes, it could.  It even does so now in one very specific situation -
> while evaluating a Configure context.  However, even playing the game
> with pushing in the value of the PSPAWN construction variable in place
> of the SPAWN variable which is what the configure code does is not a
> full solution, as scons would actually have to be prepared to gather and
> do something with the output, which it currently isn't.
>
> >
> >                      You might want to put a timeout on all sub
> > processes, ie: 5 minutes…
> >
> >                      In case they output an error and want sometype of
> > input from the human to continue
> >
> >                  Then once the subprocess has completed, (Exit success
> > or Exit Error)
> >
> >                 The responsible runner thread would:
> >
> >                        Lock the console (mutex) so other SCONS threads
> > cannot use it.
> >
> >                        output stdout and stderr of the sub process
> >
> >                        Unlock the console so other SCONS threads can use
> it.
>
> This is the method the test runner uses - queues tests, has a pool of
> runners to run them, and when one finished it takes a lock before
> writing the collected output. But that's a different usecase... the test
> runner *knows* it needs to collect output, while SCons itself really
> isn't structured that way. Using logging could also do this, as it
> handles locking between threads internally (there's an experimental
> version of the test runner that does that).
>
> It *can* be done, but would require some effort.
> _______________________________________________
> Scons-users mailing list
> [email protected]
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>

_______________________________________________
Scons-users mailing list
[email protected]
https://pairlist4.pair.net/mailman/listinfo/scons-users