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. Rob _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
