Yaakov S (Cygwin Ports) wrote:
Charles Wilson wrote:
| The attached patch (+ two new files) enables cygport to build
| "relocatable" packages using the framework devised by Bruno Haible -- if
| the upstream source supports it. Currently, only libiconv and gettext
| support this feature (coincidentally, the upstream maintainer of both
| packages is...Bruno Haible).
Forgive me for my ignorance on the topic, but what is gained through
enabling relocatibility? FWIW, I don't see Gentoo[1][2] using it, for
example. Do other distros use it?
Many times packages are compiled with hard-coded paths to resources.
E.g. if you compile foo with --prefix=/my/local/area, it's likely that
data will be installed into /my/local/area/share/foo/*, and that the
path "/my/local/area/share/foo" will be hard-coded into libfoo.so and/or
foo.exe. (also, -rpath on ELF systems, etc)
But what if you want to make a binary release that can be installed by
some user into ~/.local-packages/? (or /mnt/usb-stick/?) What if you
*don't know* where the end-user will install the binary package? (Try
http://portableapps.com/ for a real-life example, or Movable Python
http://www.voidspace.org.uk/python/movpy/)
Certainly, gentoo has no use for this; they expect everyone to recompile
everything everytime. Since GentooUserBob will compile the package
specifying his desired installation prefix, he doesn't care about
relocation after the build is complete.
Now, the Bruno said (way back when he first introduced this feature)
"I hope that people will learn when to use --enable-relocatable by
themselves. For example, I don't think a Linux distributor should use
--enable-relocatable for anything installed in /usr - it would only
be bloat that makes the system slower."
http://mail.gnu.org/archive/html/bug-gnulib/2003-04/msg00014.html
And that's true for the official cygwin dist of gettext and libiconv,
too -- the official cygwin gettext and libiconv packages are not built
with relocation support. However, I always do a test build WITH
relocation, to make sure nothing has broken. [*]
Often, something /has/ broken, and this little exercise exposes it --
and sometimes the problem thus exposed also affects the non-relocatable
build, but wasn't exposed in the "regular" build. So adding the ability
to automate relocatable builds within the cygport framework would
certainly help ME quite a bit (and not just on gettext/libiconv. I'm
working on adding relocation support to two other packages, also -- not
that the official cygwin distributed versions would actually use that
support, either).
The original relocation proposal gives a much better justification for
relocation in general than I do:
http://lists.gnu.org/archive/html/bug-gnulib/2003-03/msg00020.html
--
Chuck
[*] actually, I do a whole sequence of test builds (thanks to the fact
that libiconv and gettext are interdependent):
WITH RELOCATION
1. libiconv --disable-nls
2. gettext (link against #1, NOT installed libiconv)
3. libiconv --enable-nls (link against #2)
run test suite
4. gettext (link against #3)
run test suite
then, WITHOUT RELOCATION
5. libiconv --disable-nls
6. gettext (link against #5, NOT installed libiconv)
7. libiconv --enable-nls (link against #6)
run test suite
8. gettext (link against #7)
run test suite
The packages generated in #7 and #8 are the ones that get uploaded for
cygwin. And you wonder why I don't update libiconv/gettext very often...
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
