On Fri, Sep 21, 2018 at 11:38 AM Emil Velikov <emil.l.veli...@gmail.com> wrote: > > On 20 September 2018 at 19:19, Dylan Baker <dy...@pnwbakers.com> wrote: > > Quoting Eric Engestrom (2018-09-20 07:56:45) > >> On Thursday, 2018-09-20 15:28:09 +0100, Emil Velikov wrote: > >> > Hi Chuck, > >> > > >> > On 18 September 2018 at 16:00, Chuck Atkins <chuck.atk...@kitware.com> > >> > wrote: > >> > > 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 > >> > > > >> > > 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. > >> > > > >> > I would like to revive an idea from a few years ago: > >> > Drop the "auto" all-together. > >> > > >> > It adds a _ton_ of complexity while making the build semi-magical/not > >> > as deterministic. > >> > IIRC the Gnome people have been actively working for removing such > >> > autodetection in their packages. > >> > > >> > The only downside is that we may need to tweak our scripts _once_ to > >> > list exactly what we want to build ;-) > >> > >> _Once_ for you, because you have everything already set up, but for all > >> the new users this means that nothing will work out of the box, they'll > >> need to understand each and every options and figure out what they need > >> them set to, before they can even start. > >> > >> That sounds like a huge step backwards to me :/ > > > > Especially when one of the explicit goals was to support 4 OS families > > (Unix-like, windows, mac, haiku). To make that all work out of the box we'd > > end > > up building *nothing* by default. > > > As mentioned elsewhere - if you don't know what you're doing (it's > fine to admit that), simply follow your distribution. > If you do not trust your distribution ... well. Otherwise - read.
This would generate so many unnecessary support requests. I argued for the same thing years ago, and I've come to agree that automatically picking sane defaults is the best solution for everyone, users and developers alike (for different reasons). _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
