My only point is that I won't have the time to mess with this for a while. Only testing on Gentoo is really not enough for me to consider including this myself, because it means I will be stuck cleaning up the problems on the other platforms. If someone wants to take that project on, I fully support that.
.hc On Jun 19, 2008, at 9:04 PM, [EMAIL PROTECTED] wrote: > 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, [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. ------------------------------------------------------------------------ ---- Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
