<div dir="ltr"><div dir="ltr"><div>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.</div><div><br></div><div>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"</div><div></div><div><ul><li>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.</li><ul><li>if set to auto then missing the libva dependencies should be a failure, it should just disable the gallium va state tracker <br></li></ul><li>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.</li><ul><li>If platforms are set to auto then a failure to locate dependencies for a given platform should disable the platform.</li></ul></ul>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.  <br></div><div><br> </div><div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">----------<br>Chuck Atkins<br>Staff R&D Engineer, Scientific Computing<br>Kitware, Inc.<br></div></div></div></div></div></div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Sep 18, 2018 at 9:04 AM Eric Engestrom <<a href="mailto:eric.engestrom@intel.com">eric.engestrom@intel.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Monday, 2018-09-17 17:25:36 -0400, Marek Olšák wrote:<br>
> Where do I find default values for meson configure options?<br>
<br>
If you mean the project's options, they're in meson_options.txt;<br>
currently not printed in the output of `meson configure` though.<br>
<br>
If you mean Meson's own options (like `buildtype`), I don't think that<br>
information exists anywhere outside of Meson's source code (and it's<br>
affected by meson.build too).<br>
<br>
It might be worth opening an issue upstream to ask for and track the<br>
progress of this feature if you want it :)<br>
<br>
> <br>
> Thanks,<br>
> Marek<br>
> <br>
> On Mon, Sep 17, 2018 at 12:44 PM, Dylan Baker <<a href="mailto:dylan@pnwbakers.com" target="_blank">dylan@pnwbakers.com</a>> wrote:<br>
> > I feel like for !windows meson is in good enough shape at this point that we<br>
> > can start having the discussion about deleting the autotools build. So, is there<br>
> > anything left that autotools can do that meson cannot (that we actually want to<br>
> > implement)? And, what is a reasonable time-table to remove the autotools build?<br>
> > I think we could reasonably remove it as soon as 18.3 if others felt confident<br>
> > that it would work for them.<br>
> ><br>
> > Dylan<br>
> ><br>
> > _______________________________________________<br>
> > mesa-dev mailing list<br>
> > <a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a><br>
> > <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br>
> ><br>
> _______________________________________________<br>
> mesa-dev mailing list<br>
> <a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a><br>
> <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br>
_______________________________________________<br>
mesa-dev mailing list<br>
<a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br>
</blockquote></div>