On Tue, Jun 8, 2010 at 6:13 PM, Jakob Bornecrantz <wallbra...@gmail.com> wrote: > On Wed, Jun 9, 2010 at 2:41 AM, Dan Nicholson <dbn.li...@gmail.com> wrote: >> On Tue, Jun 8, 2010 at 5:26 PM, Jakob Bornecrantz <wallbra...@gmail.com> >> wrote: >>> On Tue, Jun 8, 2010 at 3:51 PM, Brian Paul <bri...@vmware.com> wrote: >>>> Dan Nicholson wrote: >>>>> >>>>> On Tue, Jun 8, 2010 at 3:07 AM, José Fonseca <jfons...@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 >>>>>>>> <wallbra...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
