Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#26 Patch to give mx-enabled library a different name

closed
nobody
None
5
2012-09-15
2010-12-17
Adam Williamson
No

This is a patch adapted from the one in Debian written by Joost Yervante Damad. It causes the build process to spit out a library called libGLEWmx, instead of libGLEW, when built with GLEW_MX=1...on Linux, anyway. Joost's version also patched Makefile.kfreebsd and Makefile.gnu . It's trivial to patch as many of the Makefiles as you like, but I'm working with Fedora and so only needed to change linux, and I wasn't sure entirely how many of the target arches it would be appropriate for the library to be renamed on.

The usefulness of this is that the MX support, by your admission, breaks API compatibility, so responsible distributions cannot really turn on the MX support so long as it just spits out a library called libGLEW.so.1 , as it's not actually ABI compatible with previous libGLEW.so.1's. With this change, distributions can ship a libglew-mx package containing libGLEWmx.so.1 alongside the libglew package containing libGLEW.so.1, and packages that want to build against the MX-supporting libglew can just build with -lGLEWmx instead of -lGLEW. The patch also produces a glewmx.pc to aid in this. (This bit is implemented somewhat dumbly: glewmx.pc and glew.pc are both always generated in build stage, but the appropriate one is installed at install time).

Joost's patch introduced a libsonly build target which builds only the library. I went further down this patch by splitting the install phase into two stages, install-libs and install-bin, and made the standard install target perform both of them: this allows a distro to do 'make install' then 'GLEW_MX=1 make install-libs' to install libGLEWmx without overwriting non-lib stuff (currently only the 'glewinfo' tool) from the non-MX build with the one from the MX build. (You could always just do the MX install and then the non MX install, but that's a bit fragile, this seems more elegant).

This may well need some refinement, but I wanted to submit something material at least rather than just the idea of splitting the build. This is practically useful for me for packaging Unity in Fedora; it requires the MX-enabled glew, and Ubuntu uses the Debian patch and links against libGLEWmx, so it makes sense for Fedora to do much the same; rather than Debian and Fedora implementing the same downstream patch it seems to make sense to send it back upstream.

The obvious things I can see are to figure out if targets beside Linux and FreeBSD should have this change. I also didn't bother including a static glewmx.pc , as Joost did...I don't quite see why the static glew.pc exists at all as it seems like it's always going to be regenerated from glew.pc.in when you run make. So for glewmx.pc I didn't bother.

The patch is dependent on a couple of other Fedora patches (they change lines close by, so the patch won't apply unmodified to upstream source, though the changes are small). See http://pkgs.fedoraproject.org/gitweb/?p=glew.git;a=tree patches glew-1.5.2-add-needed.patch and glew-1.5.2-makefile.patch . These may be suitable for upstreaming too, in fact.

Discussion

1 2 > >> (Page 1 of 2)
  • actually, that version always installed glew.pc (even if you'd only built glewmx). this one really installs only glewmx.pc if you're doing a glewmx install, and only installs glew.pc otherwise.

     
  • Nigel Stewart
    Nigel Stewart
    2011-01-24

    I've been looking at this, on and off. I agree in principle, it makes sense to rename MX-enabled GLEW libraries. But having a complete git-ready patch against TOT would be helpful.

     
  • I only really know Linux-y OSes, so I don't know if it makes sense to do the same change on all arches, whether there's some that don't need changing, whether there's some that would have to be changed differently...if you can give me that info I could try and give you a more complete patch. But I didn't want to go poking at OSes I know nothing about.

     
  • Nigel Stewart
    Nigel Stewart
    2011-01-24

    I think if the patch is only concerned with Linux, it will be reasonably clear what to do for the others. Keep your patch scoped to what you can test... :-)

     
  • okay, here's a git-formatted patch against the original tree (which my acronym-antenna guess is what 'ToT' means). also fixes an oversight - make dist-src wouldn't have included the glewmx.pc.in file. again, this only changes the behaviour for linux.

     
  • Nigel Stewart
    Nigel Stewart
    2011-03-11

    I'm thinking of making this change in a different way. I have a patch that I'll send to the mail list for comment and review.

     
  • Nigel Stewart
    Nigel Stewart
    2011-03-17

    A fix for this has gone into GLEW git, and will appear in GLEW 1.5.9. Hopefully this will make life easier for downstream packagers such as Fedora and Ubuntu. There are some other noticeable differences in the Debian and Fedora builds of GLEW - perhaps we can have some dialog about how to minimize those differences going forward.

    Your feedback ahead of a GLEW 1.5.9 release would be appreciated.

     
1 2 > >> (Page 1 of 2)


Anonymous


Cancel   Add attachments