Have you tested on other systems? Otherwise it's just a theory ;) 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.
.hc On Jun 18, 2008, at 8:49 PM, [EMAIL PROTECTED] wrote: > I sent a patch to patch-tracker: > http://sourceforge.net/tracker/index.php? > func=detail&aid=1997142&group_id=55736&atid=478072 > > 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 > > > [EMAIL PROTECTED] 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.a >> >> The |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. >> >> >> >> >> > > > _______________________________________________ > Pd-dev mailing list > [email protected] > http://lists.puredata.info/listinfo/pd-dev ------------------------------------------------------------------------ ---- Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
