[Scons-users] 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.

[Bill Deegan]

O.k. that's just a workaround.
MD5-timestamp decider had a bugfix between 3.0.1 and 3.0.4.  Somehow that's
causing scons to not see the dependencies to generate the nir_opcodes.h.

Regardless the way the mesa build is calling the scripts is pretty
non-standard. Though the way they add the python dependencies is pretty
clever. (And very thorough).
Calling any builder with sources set to []...

Regardless I'll see if I can get to the bottom  of why the changes to
MD5-timestamp decider are breaking this build.
You could probably just (for the time being) detect which version of scons
and if 3.0.1 or less enable md5-timestamp, otherwise let it default (which
is MD5). It's a bit slower, but theoretically more correct.

-Bill
SCons Project Co-Manager

On Mon, Feb 25, 2019 at 7:29 AM Liviu Prodea <liviuprodea at yahoo.com> wrote:

> Yes, that hack works around it. Added Jose Fonseca from VMware to this
> discussion as he is familiar with Mesa3D scons build internals.
>
>
> ==================================================================
> On Monday, February 25, 2019, 3:08:27 AM GMT+2, Bill Deegan <
> bill at baddogconsulting.com> wrote:
>
>
> Finally got around to reproducing this.
> Setting up for a build is a bit complicated, I ended up having to comment
> out a couple lines in the build.cmd
>
> o.k. Try this:
> comment out line 311 in mesascons/gallium.py
>     # env.Decider('MD5-timestamp')
>
>
>
>
> On Tue, Feb 19, 2019 at 9:42 AM Bill Deegan <bill at baddogconsulting.com>
> wrote:
>
> Curious. Those changes should only affect using MD5-timestamp decider..
>
> I'll take a look.
>
> On Tue, Feb 19, 2019 at 9:07 AM Liviu Prodea <liviuprodea at yahoo.com>
> wrote:
>
>
> =================================================================================
>
>
>
>
> Bisect is complete. I narrowed it down to 4 commits. Cannot go any further
> due to skipping of commits that don't even get at nir code base. Replay log
> is available here: https://bugs.freedesktop.org/attachment.cgi?id=143412
>
> Affected commits attempt to generate src/compiler/nir/nir.h before src/compiler/nir/nir_opcodes.h
> from their respective python sources which is obviously incorrect.
> On Monday, February 18, 2019, 8:32:34 PM GMT+2, Daniel Moody <
> dmoody256 at gmail.com> wrote:
>
>
> Which commits did you bisect too?
>
> On Mon, Feb 18, 2019, 11:37 AM Bill Deegan <bill at baddogconsulting.com
> wrote:
>
> nir_opcodes.h and any other file which are not present when needed are
> indeed relevant.
> They indicate what in the build logic is missing dependencies.
> If the dependencies were correct, then those files would be
> created/present before any file which depends on them is compiled..
>
> -Bill
>
> On Mon, Feb 18, 2019 at 1:15 AM Liviu Prodea <liviuprodea at yahoo.com>
> wrote:
>
> I am not a Mesa3D developer so I also filed a bug with them as well:
> https://bugs.freedesktop.org/show_bug.cgi?id=109443
>
>
> I dug up a bit more now that I have Scons source code at hand. It appears
> that Scons 3.0.2 that has been pulled from pypi is also affected. I tried
> bisecting between rel_3.0.1 and rel_3.0.2 branches range but when I get
> close to finish, I end up with 2 commits that are completely broken and 1
> with excessive debug that I don't know if it fails on same spot as master,
> rel_3.0.4, rel_3.0.3 or rel_3.0.2.
>
>
>
> I don't think nir_opcodes.h is relevant because if I change the
> configuration (add off-screen rendering / build llvmpipe / other changes)
> it stumbles in other header file. Also if I keep retrying building after
> failure without cleaning it succeeds eventually after plenty of tries with
> failures in random header files so it makes progress.
>
>
>
> ========================================
>
>
> On Sunday, February 17, 2019, 10:30:43 PM GMT+2, Bill Deegan <
> bill at baddogconsulting.com> wrote:
>
>
> what generates "'nir_opcodes.h" ?
> Is that output from bison/flex/some other code generator, or is that just
> a file which is checked into your tree?
>
> On Sun, Feb 17, 2019 at 2:01 AM Liviu Prodea <liviuprodea at yahoo.com>
> wrote:
>
> I applied the patch and it succeeded in getting past configuration phase
> but the end result is the same as with Scons 3.0.4 release.
>
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20190225/c952be21/attachment-0001.html>