Re: Mesa3D graphics library build failure when using Scons 3.0.3 and newer on Windows with Visual Studio 2017, Scons 3.0.1 is unaffected.

Is the windows thread/spawn bug fixed in Python now?

We have seen an infrequent issue with a race condition on windows as well.
I'm fairly certain is due to Python dropping the GIL around file
open/close..  something like env.Install(target,source), env.Program(...,
target) so a linker or other program tries to use the file after it is
copied and/or written by python Action before it's closed on the filesystem
yielding file still open errors..

Any builder with [] as the source is odd. Then adding the dependencies via
Depend(). Generally you'd specify the script.  Most build's consider that
to be sufficient. Your build goes a step further by examining all the
python modules it loads. Very clever.  I think that logic could be moved to
a python scanner and then you could get rid of most of the special logic
there.

When I get a chance I'll take a look at the rest.

On Tue, Feb 26, 2019 at 11:28 PM Jose Fonseca <[email protected]> wrote:

> On 26/02/2019 22:46, Bill Deegan wrote:
> >
> >
> > On Tue, Feb 26, 2019 at 7:57 AM Jose Fonseca <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> >     Hi Bill,
> >
> >     If you spot anything on Mesa's SCons usage that looks like a bad idea
> >     then do let us know.
> >
> >
> > Likely there's room for improvement.
> > Let me finish vetting the patch to fix your current issue and then I'll
> > see if I can find some time to do a review?
> > In the meantime if you have questions please bring them here?
>
> I don't have any concrete questions -- except this matter, SCons has
> been working fine.   My question is based upon your remarks that we're
> doing odd stuff.  I'd just would like to better understand it, and
> improve it, specially if that can avoid breakage in the future.
>
> >     One of the difficulties of Mesa is that there were always multiple
> >     build
> >     tools system, with the bulk of developers (those targeting Linux)
> using
> >     first autotools / now meson, and only a subset (those targeting
> >     Windows)
> >     using SCons.  So that's why I tried to make things somewhat
> automatic.
> >
> >     Results have been mixed: when it works, it works well; and it fails,
> >     nobody knows how to fix except me who most of this..
> >
> >
> > Have you subscribed to the scons users mailing list before today?
> > Honestly I wasn't aware Mesa was using SCons until Liviu brought it up.
>
> No, never subscribed.  We've been using it for 10+ years, and BTW, it
> has been working very well for us (ie those who build Mesa for Windows,
> VMware in particular.)  It's a pity SCons never gained traction with
> Mesa Linux developers who stuck with the autotools until last year.  If
> I had tried harder back then to get all Mesa tree fully ported to SCons
> perhaps things would have been different, but one can only do so much,
> and by then me and my team lost too many technical/political fights to
> embark on yet another one.
>
> I can only recall two instances of SCons issues affecting us, this and
> http://scons.tigris.org/issues/show_bug.cgi?id=2449 .  That was a pretty
> nasty issue to debug from my side, as the race condition was pretty
> rare.  In fact, I just realized we still have the workaround on
> https://cgit.freedesktop.org/mesa/mesa/tree/scons/fixes.py .  It's
> probably safe to drop it now :)
>
> >
> >
> >       > Calling any builder with sources set to []...
> >
> >     What should we used instead?
> >
> >
> > Most times the source for such a command is the script itself.
> > Then you'd just add the python scanner and scons should (I think) do
> > what you're manually doing via env.Depends()...
> >
> > -Bill
> >
> >
> Jose
>

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