On Wed, Mar 28, 2018 at 12:24 PM, Mark Janes <mark.a.ja...@intel.com> wrote: > Rob Herring <r...@kernel.org> writes: > >> On Wed, Mar 28, 2018 at 10:18 AM, Rob Clark <robdcl...@gmail.com> wrote: >>> On Wed, Mar 28, 2018 at 10:43 AM, Rob Herring <r...@kernel.org> wrote: >>>> On Sun, Mar 25, 2018 at 1:10 PM, Rob Clark <robdcl...@gmail.com> wrote: >>>>> I threatened to do this a long time ago.. I probably *should* have done >>>>> it a long time ago when there where many fewer intrinsics. But the >>>>> system of macro/#include magic for dealing with intrinsics is a bit >>>>> annoying, and python has the nice property of optional fxn params, >>>>> making it possible to define new intrinsics while ignoring parameters >>>>> that are not applicable (and naming optional params). And not having to >>>>> specify various array lengths explicitly is nice too. >>>>> >>>>> I think the end result makes it easier to add new intrinsics. >>>>> >>>>> v2: couple small fixes found with a test program to compare the old and >>>>> new tables >>>>> v3: misc comments, don't rely on capture=true for meson.build, get rid >>>>> of system_values table to avoid return value of intrinsic() and >>>>> *mostly* remove side-effects, add autotools build support >>>>> >>>>> Signed-off-by: Rob Clark <robdcl...@gmail.com> >>>>> --- >>>>> So, new scheme is, I think, a reasonable compromise between keeping the >>>>> python "clean" and keeping the intrinsic declarations easy to follow. >>>>> It still has the side-effect that intrinsic() adds to the table, but >>>>> drops the separate system_values table so that intrinsic() doesn't >>>>> return a value. The alternative would require the helper for various >>>>> specialized intrinsic categories to be declared far from where they are >>>>> used, which is, I think, suboptimal. And it keeps intrinsic() and >>>>> various wrappers pretty straightforward, so I don't think this should >>>>> ever pose a problem for refactoring (and certainly less of a problem >>>>> than the previous solution using cpp macros, so regardless of what your >>>>> opinion about the py code, I guess anyone could agree that this is an >>>>> improvement over the current state ;-)) >>>>> >>>>> Also added autotools build support. Sorry scons and android. (Are we >>>>> ready to drop either of these in favor of nir?) >>>> >>>> You mean meson? For Android, no. I don't see that happening anytime >>>> soon. I looked into it some by having a prebuilt target in Android.mk >>>> that calls meson. The problem is getting all the Android build >>>> environment such as include paths out of Android build system and >>>> passed into meson. I don't know how to do that in a way that is not >>>> manual and fragile. >>>> >>>> It looks like you'd just need to do some copy-n-paste of rules for >>>> Android. And you know you can push an 'android/*' branch to trigger an >>>> Android build of mesa? >>>> >>> >>> no, I didn't realize that.. on the main git tree? >> >> Yep. No one uses it AFAICT. > > I was told that this mechanism was not useful because it builds with > -Werror. Is that still true?
No. I believe I disabled that in master because mesa certainly can't build with -Werror. > Clayton implemented a buildtest for android within the i965 CI, so > anyone testing there will be notified when they break android. We are > waiting on some additional hardware before enabling it for developer > branches. I imagine you don't build all drivers or build for arm/arm64, so less useful for others. Rob _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
