Quoting Chuck Atkins (2018-09-18 08:00:44) > First, I'm fully in support of killing off autotools woo-hoo to that. And > given the substantial investment already put into the meson build that > certainly seems like a good direction to go. > > That being said, the way "auto" is currently implemented leaves quite a bit to > be desired. One of the nice features of the Autotools build was how > auto-enabled options were treated in that the dependencies were searched for > and if they were all found and met then the option would be enabled. My > experience so far with the meson build has shown this not to be the case and a > "configure" with no options has yet to be successful for me. Many of the > 'auto' options are treated as 'set to true if your platform supports it' > regardless of whether your system has the requisite dependencies available. > For example" > > • The 'gallium-va' option defaults to 'auto' but the implementation ends up > setting the '_va' option to true if the other option conditions are met, > long before libva is searched for. So then when libva isn't found one > gets > an error. > □ if set to auto then missing the libva dependencies should be a > failure, > it should just disable the gallium va state tracker
This is a bug I noticed earlier, I think I have a patch for it I just never sent out apparently. I've send that out now. > • The platform options set to 'auto' has a set of checks to determine which > platforms are enabled as required. If the system_has_kms_drm check is > true > then Wayland is enabled as required. Later if the check for wayland > dependencies fails, an error occurs. > □ If platforms are set to auto then a failure to locate dependencies for > a given platform should disable the platform. > > I realize these are just two specific examples, each of which can be readily > dealt with in their own specific way so I'm not asking "how to I address #1 > and > #2?" because I can certainly do that. These are just two instances of many > though in the way "auto" is dealt with. My point is really a broader one that > before meson becomes the primary build then the behavior of "auto" should > create a successful configure out of the box without additional options. This is a much harder thing to fix, I'll look into it, but it'll take at least a few days to get this done. > > ---------- > Chuck Atkins > Staff R&D Engineer, Scientific Computing > Kitware, Inc. > > > On Tue, Sep 18, 2018 at 9:04 AM Eric Engestrom <eric.engest...@intel.com> > wrote: > > On Monday, 2018-09-17 17:25:36 -0400, Marek Olšák wrote: > > Where do I find default values for meson configure options? > > If you mean the project's options, they're in meson_options.txt; > currently not printed in the output of `meson configure` though. > > If you mean Meson's own options (like `buildtype`), I don't think that > information exists anywhere outside of Meson's source code (and it's > affected by meson.build too). > > It might be worth opening an issue upstream to ask for and track the > progress of this feature if you want it :) > > > > > Thanks, > > Marek > > > > On Mon, Sep 17, 2018 at 12:44 PM, Dylan Baker <dy...@pnwbakers.com> > wrote: > > > I feel like for !windows meson is in good enough shape at this point > that we > > > can start having the discussion about deleting the autotools build. > So, > is there > > > anything left that autotools can do that meson cannot (that we > actually > want to > > > implement)? And, what is a reasonable time-table to remove the > autotools build? > > > I think we could reasonably remove it as soon as 18.3 if others felt > confident > > > that it would work for them. > > > > > > Dylan > > > > > > _______________________________________________ > > > mesa-dev mailing list > > > mesa-dev@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > > > > > _______________________________________________ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev >
signature.asc
Description: signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
