GNOME Bugzilla – Bug 593888
Allow for overriding gnome-screensaver libexec dir
Last modified: 2009-09-02 15:44:03 UTC
Hi f-spot's configure.ac has logic to use gnome-screensaver.pc's vars to compute various gnome-screensaver dirs (good). If the .pc isn't present, one can optionally override the gnome-screensaver prefix and f-spot's configure.ac will use standard gnome-screensaver dirs relative to this prefix, except for gnome-screensaver's privlibexecdir where f-spot will try gssprefix/lib/screensaver and use that if present. Now I guess the intent is that basically if the .pc or gnome-screensaver is installed, this just does the right thing, but under Debian/Ubuntu gnone-screensaver has no separate package for the .pc (that would be overkill) and it's expensive + ugly to pull gnome-screensaver as a build-dep. If we dont pull gnome-screensaver as a build-dep, we cant override the default of libexec which is the incorrect dir. Hence I worked on a series of patches to cleanup the current logic making is slightly more autoconf-ish and extending the logic to allow overriding any gnome-screensaver dir which f-spot still autodetects by default, as before. I'll attach a mbox of patches; hope that's ok; is there a place on git.gnome.org for user branches proposed for merging in module branches? I have account "lool". Cheers,
BTW you might want to ship /autogen.sh via /Makefile.am's EXTRA_DIST; I see it's not included in the tarball right now.
Created attachment 142308 [details] mbox of patches reworking --with-gnome-screensaver flags Passed basic build testing; FYI there's an install issue with sv/f-spot.xml with current git.
(In reply to comment #1) > BTW you might want to ship /autogen.sh via /Makefile.am's EXTRA_DIST; I see > it's not included in the tarball right now. no, we don't want to
(In reply to comment #0) > I'll attach a mbox of patches; hope that's ok; is there a place on > git.gnome.org for user branches proposed for merging in module branches? y, that's ok. we also use gitorious for user branches and merge requests. http://gitorious.org/f-spot
Patches looks ok, pushed
(In reply to comment #3) > (In reply to comment #1) > > BTW you might want to ship /autogen.sh via /Makefile.am's EXTRA_DIST; I see > > it's not included in the tarball right now. > > no, we don't want to Running autogen.sh creates a ton of makefiles and a configure script. It requires users to have the full development stack (automake etc). A configured tree on the other hand only requires bash and make to build. That's why autogen.sh is never included in the tarball, it's a development tool which requires a lot of applications to work. Not requiring our users to have these applications makes it a lot easier for them to build.
Well, on autogen.sh, I dont strictly need it as I used a git checkout, but consider that it's part of your development scripts and hence should be part of your release. It's common for other modules to include it. I personally appreciate when modules are fully contained in their tarballs, and while it's not common that I run ./autogen.sh in a tarball, I did actually do that from time to time. Yes, it requires some different software to be used than what's needed to build with ./configure && make; I think that's alright. (FYI the GPL mentions that you should provide source code but also scripts to modify the work. I certainly wouldn't be one to hold you to this part of the license in tarball releases, but I think it would be a valid argument in favor of simply shipping all scripts not specific to a git repo with the tarball release.)