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.

On Tue, Feb 26, 2019 at 7:57 AM Jose Fonseca <[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?


>
> 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 <[email protected]
> > <mailto:[email protected]>> 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
> >     <[email protected] <mailto:[email protected]>>
> 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
> >     <[email protected] <mailto:[email protected]>>
> 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
> >         <[email protected] <mailto:[email protected]>> 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
> >             <[email protected] <mailto:[email protected]>> wrote:
> >
> >
> >             Which commits did you bisect too?
> >
> >             On Mon, Feb 18, 2019, 11:37 AM Bill Deegan
> >             <[email protected]
> >             <mailto:[email protected]> 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
> >                 <[email protected] <mailto:[email protected]>>
> >                 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 <[email protected]
> >                     <mailto:[email protected]>> 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
> >                     <[email protected]
> >                     <mailto:[email protected]>> 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
[email protected]
https://pairlist4.pair.net/mailman/listinfo/scons-users