[Mesa-dev] RFC: Drop glew from mesa

[Jakob Bornecrantz]

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?

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.


>
>> Can we do the same to glu and glw?
>>
>> Giving "--disable-glu --disable-glw --disable-glut" as arguments to
>> configure is getting old.
>
> Again, people/distros use these as their system glu and glw, so you
> can't just drop them from the mesa repo without moving them to an
> alternate location. However, we can easily make configure default to
> not building them.

Sorry communication error on my part, thats what I wanted to do, just
as long as I don't have to deal with them in Mesa. Move them either to
the demos repo (but that feels like shuffling lint from one pocket to
another), or their own separate repository. I'm perfectly content with
using the ones from my distro, they have hardly changed in the last
past 5 years.

Cheers Jakob.