Hans-Christoph Steiner ha scritto:
Have you tested on other systems? Otherwise it's just a theory ;)
code is NOT theory (supposed one knows how to write it)! if you read and understand the patch, you will agree that that change is harmless, as it doesn't change anything unless one invokes install with 'make DESTDIR=/path install'
I tested the change on all my Gentoo boxes (x86 and ppc archs; please if you have an amd64 do test it).
the ebuild does the patching since always (you find the same patch posted to the tracker in pd-overlay/media-sound/pd-extended/files)
that's also the reason because pd was removed from the official Gentoo tree (when I asked, they said "because build system was horribly broken")
The Pd-extended build system uses DESTDIR to build all of the packages, so there is a workable way to use it as it is now. I am all for improving it, as long as it doesn't break anything.
I'm not criticizing the pd-extended build system, but the pd's makefile(.am) which still has incomplete DESTDIR support[*]. (though pd-extended seems to use the same makefile.am)
[*]: DESTDIR has been thrown here and there, but is NOT prepended on every installed file (and I don't understand why)
On Jun 18, 2008, at 8:49 PM, mescalinum@gmail.com wrote:
I sent a patch to patch-tracker: http://sourceforge.net/tracker/index.php?func=detail&aid=1997142&gro...
while patching the makefile.in, I realized that DESTDIR support partly was there; only some items were not installed under $(DESTDIR).
did someone forgot to add $(DESTDIR)?
btw, the patch is ok to apply for every system, as when $(DESTDIR) is not defined (and most users will leave it undefined), makefile acts just like did before.
cheers, Federico Ferri
mescalinum@gmail.com ha scritto:
would be nice for this change to be included in all pd releases. note that actually Pd must be patched [1] for making it install on Gentoo without the QA tool reporting access violations.
[1] one-liner fix: sed -i -e 's:($(libdir)/pd):$(DESTDIR)\1:' makefile.in
[from http://www.gnu.org/prep/standards]
|DESTDIR| is a variable prepended to each installed target file, like this:
$(INSTALL_PROGRAM) foo $(DESTDIR)$(bindir)/foo $(INSTALL_DATA) libfoo.a $(DESTDIR)$(libdir)/libfoo.aThe |DESTDIR| variable is specified by the user on the |make| command line as an absolute file name. For example:
make DESTDIR=/tmp/stage install|DESTDIR| should be supported only in the |install*| and |uninstall*| targets, as those are the only targets where it is useful.
If your installation step would normally install /usr/local/bin/foo and /usr/local/lib/libfoo.a, then an installation invoked as in the example above would install /tmp/stage/usr/local/bin/foo and /tmp/stage/usr/local/lib/libfoo.a instead.
Prepending the variable |DESTDIR| to each target in this way provides for staged installs, where the installed files are not placed directly into their expected location but are instead copied into a temporary location (|DESTDIR|). However, installed files maintain their relative directory structure and any embedded file names will not be modified.
You should not set the value of |DESTDIR| in your Makefile at all; then the files are installed into their expected locations by default. Also, specifying |DESTDIR| should not change the operation of the software in any way, so its value should not be included in any file contents.
|DESTDIR| support is commonly used in package creation. It is also helpful to users who want to understand what a given package will install where, and to allow users who don't normally have permissions to install into protected areas to build and install before gaining those permissions. Finally, it can be useful with tools such as |stow|, where code is installed in one place but made to appear to be installed somewhere else using symbolic links or special mount operations. So, we strongly recommend GNU packages support |DESTDIR|, though it is not an absolute requirement.