[Mesa-dev] [PATCH-RFC] autoconf: add --enable-{dri,glx,osmesa}

[Chia-I Wu]

On Tue, Jun 28, 2011 at 4:17 AM, Dan Nicholson <dbn.lists at gmail.com> wrote:
> On Sun, Jun 26, 2011 at 6:39 AM, Chia-I Wu <olvaffe at gmail.com> wrote:
>> From: Chia-I Wu <olv at lunarg.com>
>>
>> The idea is that DRI driver, libGL and libOSMesa are libraries that can
>> be independently enabled, yet --with-driver does not allow us to easily
>> do that, if not impossible.  This also matches what
>> --enable-{egl,xorg,d3d1x} do for the respective libraries.
>
> I haven't read this in any detail, but I definitely like the idea.
> When I originally wrote all this, I struggled to coordinate DRI vs.
> GLX, and I didn't really bother with the EGL code that was mostly
> experimental. This is much more coherently structured.
Great.
>> There are two libGL providers: Xlib-based and DRI-based.  They cannot
>> coexist.  To be able to choose between them, --enable-xlib-glx is also
>> added.
>
> This is the only part that kind of bugs me. It seems to me that the
> --enable-dri and --enable-xlib-glx options aren't really symmetric. I
> believe you'd need this to be --enable-dri-glx to really act as a
> provider. I can see why you didn't do that since dri is a "provider"
> to many of the APIs and would require a lot more hacking of
> configure.ac. Is my understanding of that correct? I'm not as familiar
> with the newer non-GL Mesa components.
I would like APIs to be enabled in the most straightforward ways.
Say, when I need GLX and D3D1X, I should be able to express that by
specifying

  --enable-glx --enable-d3d1x
  (--enable-glx is redundant as it is default on)

These API options are the high-level ones.

Then there are lower levels of options to change how APIs are
implemented.  Users usually don't need to care about these options as
we pick the best we have by default (finger crossed).  Examples of
such options are, for GLX,

  --enable-xcb  Use XCB in DRI-based GLX
  --enable-driglx-direct  Support direct rendering in DRI-based GLX
  (here DRI-based actually means {GLX/DRI2}PROTO-based)
  --enable-xlib-glx  Use Xlib-based GLX instead
  (and the first two options become irrelevant)

For DRI, there is --enable-shared-dricore; for EGL, there is
--enable-gallium-egl.  And so on.

This is the idea behind those options.  I hope this expresses my idea
more clear, and help us come up with a more systematical way to name
the options.

> --
> Dan
>



-- 
olv at LunarG.com