[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
bill at baddogconsulting.com
Tue Feb 26 17:46:48 EST 2019
On Tue, Feb 26, 2019 at 7:57 AM Jose Fonseca <jfonseca at vmware.com> 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?
>
> 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.
>
> > 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
>
> On 25/02/2019 19:29, Bill Deegan wrote:
> > 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
> > <mailto: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 <mailto: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 <mailto: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 <mailto: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
> > <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.freedesktop.org%2Fattachment.cgi%3Fid%3D143412&data=02%7C01%7Cjfonseca%40vmware.com%7C7b7ce65c2b0f40ea107208d69b57a932%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C636867198189064715&sdata=kiM4jHVtvSyqaKqtlOhQf0v4ZMGgceLSg5yTLvUP6bY%3D&reserved=0
> >
> >
> > 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 <mailto: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
> > <mailto: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 <mailto: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
> > <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.freedesktop.org%2Fshow_bug.cgi%3Fid%3D109443&data=02%7C01%7Cjfonseca%40vmware.com%7C7b7ce65c2b0f40ea107208d69b57a932%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C636867198189064715&sdata=fTvbHUX4GIPYcvSZXksXZ%2FVETpHkk7BN1IKXT4U1VgM%3D&reserved=0
> >
> >
> >
> > 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
> > <mailto: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
> > <mailto: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.
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20190226/27fd521c/attachment-0001.html>
More information about the Scons-users
mailing list