Bug 130418

Created attachment 227098 [details] Patch

Comment on attachment 227098 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=227098&action=review > ChangeLog:8 > + When building GStreamer from git, it uses libtool, which creates libgstwhatever.la, > + but the real library goes in .libs/libgstwhatever.so. Another approach > + would be to compile with libtool, but that's much more involved. This doesn't look like a very good reason to do this: why should this be done only to GStreamer and not any other dependency that is built with libtool? Why not just install your GStreamer copy somewhere and deal with it normally? This approach seems like a weird workaround for a very specific situation to me.

(In reply to comment #2) > This doesn't look like a very good reason to do this: why should this be done only to GStreamer and not any other dependency that is built with libtool? Why not just install your GStreamer copy somewhere and deal with it normally? This approach seems like a weird workaround for a very specific situation to me. Because this is how GStreamer is meant to be used: http://gstreamer.freedesktop.org/data/doc/gstreamer/head/faq/html/chapter-developing.html#idp55212752 I doubt many people will need to use this, but it's a trivial change that makes working with git checkouts of GStreamer significantly easier.

(In reply to comment #3) > (In reply to comment #2) > > This doesn't look like a very good reason to do this: why should this be done only to GStreamer and not any other dependency that is built with libtool? Why not just install your GStreamer copy somewhere and deal with it normally? This approach seems like a weird workaround for a very specific situation to me. > > Because this is how GStreamer is meant to be used: > > http://gstreamer.freedesktop.org/data/doc/gstreamer/head/faq/html/chapter-developing.html#idp55212752 I fail to see anything GStreamer-specific in this link, the content there applies to any libtool project -- it's all about changing environment variables. > I doubt many people will need to use this, but it's a trivial change that makes working with git checkouts of GStreamer significantly easier. My concern with this approach is that it's basically an undocumented hack for a very specific use case. If you have already modified your other environment variables (PKG_CONFIG_PATH, for example, since you are relying on its output in the patch), wouldn't it work if you also just changed CMAKE_LIBRARY_PATH locally?

(In reply to comment #4) > If you have already modified your other environment variables (PKG_CONFIG_PATH, for example, since you are relying on its output in the patch), wouldn't it work if you also just changed CMAKE_LIBRARY_PATH locally? The whole point of gst-git is that it sets up PKG_CONFIG_PATH automatically. Hard-coding every library directory is a much bigger hack than just looking in the libtool .libs directory. And there are hundreds of them, which change every time a new plugin is added to GStreamer..

I also find it frustrating that it worked until we switched to CMake..

(In reply to comment #4) > My concern with this approach is that it's basically an undocumented hack for a very specific use case. I could also document this with a comment that we're looking in .libs because GStreamer's git checkouts automatically use libtool, which puts libraries in .libs.

philn, do you use a git checkout of GStreamer? If so, how do you handle building against it in WebKit?

(In reply to comment #5) > (In reply to comment #4) > > If you have already modified your other environment variables (PKG_CONFIG_PATH, for example, since you are relying on its output in the patch), wouldn't it work if you also just changed CMAKE_LIBRARY_PATH locally? > > The whole point of gst-git is that it sets up PKG_CONFIG_PATH automatically. Hard-coding every library directory is a much bigger hack than just looking in the libtool .libs directory. And there are hundreds of them, which change every time a new plugin is added to GStreamer.. Doesn't `gst-git && export CMAKE_LIBRARY_PATH=${LD_LIBRARY_PATH}' work? Additionally, if you just build GStreamer with ./autogen.sh won't the .pc files have "prefix=/usr/local" and thus the current patch will tell CMake to look at /usr/local/lib/.libs?

(In reply to comment #8) > philn, do you use a git checkout of GStreamer? If so, how do you handle building against it in WebKit? I usually rely on the version we have in jhbuild, which I make point to trunk whenever needed.

Sorry, I didn't get emailed about the responses on here for some reason. I'll look into just using the jhbuild to do what I need (and hopefully GStreamer will fix this eventually).