[Mesa-dev] RFC: Drop glew from mesa

[Dan Nicholson]

On Tue, Jun 8, 2010 at 6:13 PM, Jakob Bornecrantz <wallbraker at gmail.com> wrote:
> On Wed, Jun 9, 2010 at 2:41 AM, Dan Nicholson <dbn.lists at gmail.com> wrote:
>> On Tue, Jun 8, 2010 at 5:26 PM, Jakob Bornecrantz <wallbraker at gmail.com> wrote:
>>> On Tue, Jun 8, 2010 at 3:51 PM, Brian Paul <brianp at vmware.com> wrote:
>>>> Dan Nicholson wrote:
>>>>>
>>>>> On Tue, Jun 8, 2010 at 3:07 AM, José Fonseca <jfonseca at vmware.com> wrote:
>>>>>>
>>>>>> On Mon, 2010-06-07 at 07:36 -0700, Brian Paul wrote:
>>>>>>>
>>>>>>> Jakob Bornecrantz wrote:
>>>>>>>>
>>>>>>>> On Sat, Jun 5, 2010 at 6:03 PM, Jakob Bornecrantz
>>>>>>>> <wallbraker at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> Since we don't have any progs in mesa that uses glew anymore is it
>>>>>>>>> okay if we drop it? I have attached a patch which drops it its a bit
>>>>>>>>> big so I packed it. And here is the change thingy:
>>>>>>>>>
>>>>>>>>>  configs/beos           |    2 +-
>>>>>>>>>  configs/darwin         |    2 +-
>>>>>>>>>  configs/default        |    4 +-
>>>>>>>>>  configs/freebsd-dri    |    2 +-
>>>>>>>>>  configs/linux-cell     |    2 +-
>>>>>>>>>  configs/linux-dri-xcb  |    2 +-
>>>>>>>>>  configs/linux-indirect |    2 +-
>>>>>>>>>  configure.ac           |    2 +-
>>>>>>>>>  include/GL/glew.h      |14435
>>>>>>>>> ------------------------------------------------
>>>>>>>>>  include/GL/glxew.h     | 1476 -----
>>>>>>>>>  include/GL/wglew.h     | 1247 -----
>>>>>>>>>  src/SConscript         |    1 -
>>>>>>>>>  src/glew/LICENSE.txt   |   73 -
>>>>>>>>>  src/glew/Makefile      |   54 -
>>>>>>>>>  src/glew/SConscript    |   69 -
>>>>>>>>>  src/glew/glew.c        |14320
>>>>>>>>> -----------------------------------------------
>>>>>>>>>  src/glew/glewinfo.c    | 8441 ----------------------------
>>>>>>>>>  src/glew/visualinfo.c  | 1173 ----
>>>>>>>>>  18 files changed, 8 insertions(+), 41299 deletions(-)
>>>>>>>>
>>>>>>>> This got stuck in the moderation queue, resending without the patch.
>>>>>>>
>>>>>>> Looks good.
>>>>>>>
>>>>>>> But it would be handy to have glew in the mesa-demos tree so that we
>>>>>>> don't all have find/install the latest version.
>>>>>>
>>>>>> Yes.
>>>>>>
>>>>>> And glut, could we move glut to demos too? It would make building on
>>>>>> windows easy again.
>>>>>
>>>>> glut might be something that deserves its own repo since some people
>>>>> use Kilgard's glut as their system glut. Requiring them to get that
>>>>> from a demos package seems a little odd. But splitting it out of the
>>>>> main mesa package seems nice, if not just for licensing reasons.
>>>>
>>>> I'd be OK with that, but please don't remove it until glut is set up
>>>> somewhere else, either in the demo repo or a new repo.
>>>>
>>>> I could move the glew sources into the demo tree but someone else will have
>>>> to setup the automake stuff.
>>>
>>> I'm sure we can also make automake detect if glu and glut is installed
>>> and use the system ones instead of the ones shipping within the demos
>>> repo (also overridden with a option).
>>
>> What I'd like to do sooner or later is add *-uninstalled.pc files to
>> the repo to support the "I want to link the demos against the libGL in
>> my mesa tree" case that I figure lots of developers use. Then you
>> could just do PKG_CONFIG_PATH=$HOME/src/mesa and the demo tree would
>> never know the difference.
>
> Or just use GL_CFLAGS=-I$HOME/src/mesa/include
> GL_LDFLAGS=-L$HOME/src/mesa/lib ./configure, but I guess the
> *-uninstalled.pc is less typing. Tho can .pc point to directories
> relative to the location of the .pc file?

I'm not 100% sure how it works, but here's an example:

http://git.gnome.org/browse/glib/tree/glib-2.0-uninstalled.pc.in

I think the "relative to .pc file" part is ${pcfiledir}, although
${pc_top_builddir} is confusing me.

> That will help for linking but not running without setting up
> LD_LIBRARY_PATH, tho I know automake can generate wrapper scripts if
> you use progname_LDADD = my_lib.la that picks up the right library at
> run time (see drm.git/tests/kmstest). I dunno if it will do the right
> thing with libraries added via AM_LDFLAGS, or ones external to the
> current build.

This is actually a libtool generated wrapper script. It's one of the
really nice features of libtool, and it usually works pretty well for
both internal and external libraries.

--
Dan