Re: [PD] installing netpd under gentoo using layman error maxlib
so what you got there with /usr/lib/pd and doc/ in there ?? who does that belong to to whatever ..check it out and emerge --resume then .. ah, seems you got FEATURES=userpriv - so you might diasable thet .. but seems actually this a bug in the ebuild , it shouldn't try making that directory at 'install' stage. directories are made at the 'merge' stage ACCESS DENIED mkdir: /usr/lib/pd/doc install: cannot create directory `/usr/lib/pd/doc': Permission denied make: *** [install] Error 1 /usr/portage/local/layman/pd-overlay/media-plugins/maxlib/maxlib-.ebuild: line 32: emake install failed: command not found Completed installing maxlib- into /var/tmp/portage/media-plugins/maxlib-/image/ --- ACCESS VIOLATION SUMMARY --- LOG FILE = /var/log/sandbox/sandbox-media-plugins_-_maxlib--512.log mkdir: /usr/lib/pd/doc i will get netpd and build from the main site; i know it will work like that. /a yeah, i think that's the ebuild which isn't very well written. i wish i have done some ebuild .. but i only need a few externals - so compiled those manualy into my own prefix ;) ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] installing netpd under gentoo using layman error maxlib
so what you got there with /usr/lib/pd and doc/ in there ?? who does that belong to to whatever ..check it out and emerge --resume then .. no way-.- ah, seems you got FEATURES=userpriv - so you might diasable thet .. but seems actually this a bug in the ebuild , it shouldn't try making that directory at 'install' stage. CVS ebuilds (ebuilds that pull sources from VC repositories) are a hell. I promised myself to make periodically snapshots, so I wouldn't had such issues. at te time I wrote the ebuild it worked fine. directories are made at the 'merge' stage ACCESS DENIED mkdir: /usr/lib/pd/doc install: cannot create directory `/usr/lib/pd/doc': Permission denied make: *** [install] Error 1 it seems that Makefile system ignored DESTDIR DESTDIR is an environment variable for staged installs. and Gentoo does staged installs. it means it does not install directly into /usr/lib, but first does install tasks inside a sandbox, chrooted in $DESTDIR directory. if makefile tries to write directly to root / filesystem (thus, not respecting the DESTDIR directive) it raises that Access Violation error above I'll fix as soon as I have time thanks for reporting -- Federico Ferri ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] installing netpd under gentoo using layman error maxlib
the Makefiles in the pd CVS tree are very are definetly not good. they needs fixing globaly. who is responsible for the CVS ? i think that all of them have to be generalised ,so we can easiely build anything. i do everything manually on my system, cause quite a few makefiles try to use -m32 in CFLAGS and many of them need -fPIC to be added. there basic externals , which don't have any ./configure part, i think we need to work on those first , leaving Gem and DataFlow aside .. also there is acouple of external which have duplicated objects. i'm not totaly experienced with writing from the scratch makefiles, but i could help checking it out on amd64 (gentoo).. and hopefully mac-ppc (obsd) soon as well. On Tue, Nov 20, 2007 at 10:01:05AM +0100, [EMAIL PROTECTED] wrote: so what you got there with /usr/lib/pd and doc/ in there ?? who does that belong to to whatever ..check it out and emerge --resume then .. no way-.- ah, seems you got FEATURES=userpriv - so you might diasable thet .. but seems actually this a bug in the ebuild , it shouldn't try making that directory at 'install' stage. CVS ebuilds (ebuilds that pull sources from VC repositories) are a hell. I promised myself to make periodically snapshots, so I wouldn't had such issues. at te time I wrote the ebuild it worked fine. directories are made at the 'merge' stage ACCESS DENIED mkdir: /usr/lib/pd/doc install: cannot create directory `/usr/lib/pd/doc': Permission denied make: *** [install] Error 1 it seems that Makefile system ignored DESTDIR DESTDIR is an environment variable for staged installs. and Gentoo does staged installs. it means it does not install directly into /usr/lib, but first does install tasks inside a sandbox, chrooted in $DESTDIR directory. if makefile tries to write directly to root / filesystem (thus, not respecting the DESTDIR directive) it raises that Access Violation error above I'll fix as soon as I have time thanks for reporting -- Federico Ferri ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] installing netpd under gentoo using layman error maxlib
[EMAIL PROTECTED] wrote: the Makefiles in the pd CVS tree are very are definetly not good. they needs fixing globaly. who is responsible for the CVS ? nobody. the authors are responsible for their stuff. so: if zexy/src/Makefile is broken, it is my fault... i think that all of them have to be generalised ,so we can easiely build anything. i do everything manually on my system, cause quite a few makefiles try to use -m32 in CFLAGS and many of them need -fPIC to be added. at least the pd-sources (+externs) have fixed this by now. i think the (erroneous) use of the -m32 flag in pd-0.40 convinced several developers to add this flag to their makefiles. there basic externals , which don't have any ./configure part, i think we need to work on those first , leaving Gem and DataFlow aside .. GridFlow you mean? also there is acouple of external which have duplicated objects. what do you mean here? nameclashes? duplicated functionality? aliases? fmga.sdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] installing netpd under gentoo using layman error maxlib
the Makefiles in the pd CVS tree are very are definetly not good. they needs fixing globaly. who is responsible for the CVS ? i think that all of them have to be generalised ,so we can easiely build anything. i do everything manually on my system, cause quite a few makefiles try to use -m32 in CFLAGS and many of them need -fPIC to be added. there basic externals , which don't have any ./configure part, i think we need to work on those first , leaving Gem and DataFlow aside .. also there is acouple of external which have duplicated objects. i'm not totaly experienced with writing from the scratch makefiles, but i could help checking it out on amd64 (gentoo).. and hopefully mac-ppc (obsd) soon as well. heh, it would be a definitely GOOD THING to tidy up our build systems. but HOW? one solution could be modularizing and hierarchicalizing Makefiles perhaps pd-extended build system uses this approach (Hans, can you spend some words here?). another approach could be auto*-tools, but I don't know anything about that. if anyone has experience with that and he thinks it is reasonable to use autoconf/automake it would be appreciated if he can write some lines on the wiki, describing a standardized build procedure for externals based on autotools writing Makefiles it means much more than making a bunch of C files to compile. the end user just use the compile part, but other environments (see the Gentoo build system) use more advanced Makefiles features. I just mention some: - CC, STRIP, LD, ... variables can override the default programs - DESTDIR is used as filesystem root for staged installs - test target is used to perform tests - CFLAGS, CXXFLAGS *must* be honored instead of hardcoding CFLAGS (like -march, -mcpu, -funroll-loops, -fomit-frame-pointer, -fpipe, ...) into Makefiles I wrote very few externs (notemono, tracker) and I should admit even my makefiles are broken and don't respect all of the above features writing a Makefile by hand is a PITA and much error-prone :| just my 0.02 Euro -- Federico Ferri ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] installing netpd under gentoo using layman error maxlib
On Tue, Nov 20, 2007 at 01:56:19PM +0100, IOhannes m zmoelnig wrote: [EMAIL PROTECTED] wrote: the Makefiles in the pd CVS tree are very are definetly not good. they needs fixing globaly. who is responsible for the CVS ? nobody. the authors are responsible for their stuff. so: if zexy/src/Makefile is broken, it is my fault... i think that all of them have to be generalised ,so we can easiely build anything. i do everything manually on my system, cause quite a few makefiles try to use -m32 in CFLAGS and many of them need -fPIC to be added. at least the pd-sources (+externs) have fixed this by now. i think the (erroneous) use of the -m32 flag in pd-0.40 convinced several developers to add this flag to their makefiles. i kidda realise thatr as well . there basic externals , which don't have any ./configure part, i think we need to work on those first , leaving Gem and DataFlow aside .. GridFlow you mean? ah , sure yeah :) also there is acouple of external which have duplicated objects. what do you mean here? nameclashes? duplicated functionality? aliases? yeah ..i can't remenber, but when i used my strategy: #' foreach pde (`find -iname '*.pd_linux'`) ln -s $pde /opt/audio/lib/pd/ext/cvs-all/ end #' i found some file with the same names .., and they seemd to copy some stuff from on external directory into anothr in order to resolvetheir little dependency , i suppose .. such things should be included in some guidelines may be, if we wish to have any guide lines as such . fmga.sdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] installing netpd under gentoo using layman error maxlib
On Tue, Nov 20, 2007 at 04:59:18PM +0100, [EMAIL PROTECTED] wrote: heh, it would be a definitely GOOD THING to tidy up our build systems. but HOW? i think of having one Makeglobal which will contain DESTDIR, CFALGS , *FLAGS ..etc all the general variebles.. and procedures (or how do you call it in make terminology ?) - ah targets may be .. i mean the way you wanna do make install and make clean .. etc i'd suggect make syminst (which will link .pd and .pd_linux) files into the path instead of copying it - save a litle space (practicaly) AND make update of the abstraction very simple! so there we set like all the abstractions to go into $libdir/abs or something that you perefere .. and the externals can go into $libdir/ext - stick to 3char convention is a good idea i think (once the situation permits)! so i'm just giving some organizational idea ..(i organize my installation in that manner actually). so having this Makeglobal (or ..Makefile.glob if you wish), athors just add their Makelocal's which will only contain the compilation procedure definition. one solution could be modularizing and hierarchicalizing Makefiles perhaps pd-extended build system uses this approach (Hans, can you spend some words here?). another approach could be auto*-tools, but I don't know anything about that. if anyone has experience with that and he thinks it is reasonable to use autoconf/automake it would be appreciated if he can write some lines on the wiki, describing a standardized build procedure for externals based on autotools i think we don't really need autoconf or any of those - having the above structure one can just go into the external's dir and do make install or make syminst we don't need --with-blah and --enable-foo for simple externals , i reckon apart from massive things like GridFlow and GEM ..(which have already got it ;) writing Makefiles it means much more than making a bunch of C files to compile. the end user just use the compile part, but other environments (see the Gentoo build system) use more advanced Makefiles features. I just mention some: - CC, STRIP, LD, ... variables can override the default programs - DESTDIR is used as filesystem root for staged installs - test target is used to perform tests - CFLAGS, CXXFLAGS *must* be honored instead of hardcoding CFLAGS (like -march, -mcpu, -funroll-loops, -fomit-frame-pointer, -fpipe, ...) into Makefiles I wrote very few externs (notemono, tracker) and I should admit even my makefiles are broken and don't respect all of the above features writing a Makefile by hand is a PITA and much error-prone :| i don't think it's a big deal to have some basic makefile structure like that .. ok, well if we got any auto-tools specialist , who has a good solution now around here .. just my 0.02 Euro -- Federico Ferri ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] installing netpd under gentoo using layman error maxlib
[EMAIL PROTECTED] wrote: also there is acouple of external which have duplicated objects. what do you mean here? nameclashes? duplicated functionality? aliases? yeah ..i can't remenber, but when i used my strategy: #' foreach pde (`find -iname '*.pd_linux'`) ln -s $pde /opt/audio/lib/pd/ext/cvs-all/ end #' i found some file with the same names .., and they seemd to copy some stuff from on external directory into anothr in order to resolvetheir little dependency , i suppose .. such things should be included in some guidelines may be, if we wish to have any guide lines as such . there are several solutions to this (and have been discussed to death on this list before) one of them is to use prefixes (see libdir) another one is to avoid nameclashes in the 1st place (needs a lot of communication); a start for a centralized repository of object-names is the pdpedia project. mfga.dsr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] installing netpd under gentoo using layman error maxlib
The Pd-extended Makefiles do use DESTDIR, CFLAGS, etc. but are only somewhat hierarchical. That stuff could be greatly improved for sure. Patches welcome :D I think that it autoconf/config.h should be the technique for handling libs and other dependencies. Perhaps automake would be useful in the long run, Bryan Jurish outlined how to use it with Pd on this list a little while ago. .hc On Nov 20, 2007, at 11:34 AM, [EMAIL PROTECTED] wrote: On Tue, Nov 20, 2007 at 04:59:18PM +0100, [EMAIL PROTECTED] wrote: heh, it would be a definitely GOOD THING to tidy up our build systems. but HOW? i think of having one Makeglobal which will contain DESTDIR, CFALGS , *FLAGS ..etc all the general variebles.. and procedures (or how do you call it in make terminology ?) - ah targets may be .. i mean the way you wanna do make install and make clean .. etc i'd suggect make syminst (which will link .pd and .pd_linux) files into the path instead of copying it - save a litle space (practicaly) AND make update of the abstraction very simple! so there we set like all the abstractions to go into $libdir/abs or something that you perefere .. and the externals can go into $libdir/ext - stick to 3char convention is a good idea i think (once the situation permits)! so i'm just giving some organizational idea ..(i organize my installation in that manner actually). so having this Makeglobal (or ..Makefile.glob if you wish), athors just add their Makelocal's which will only contain the compilation procedure definition. one solution could be modularizing and hierarchicalizing Makefiles perhaps pd-extended build system uses this approach (Hans, can you spend some words here?). another approach could be auto*-tools, but I don't know anything about that. if anyone has experience with that and he thinks it is reasonable to use autoconf/automake it would be appreciated if he can write some lines on the wiki, describing a standardized build procedure for externals based on autotools i think we don't really need autoconf or any of those - having the above structure one can just go into the external's dir and do make install or make syminst we don't need --with-blah and --enable-foo for simple externals , i reckon apart from massive things like GridFlow and GEM ..(which have already got it ;) writing Makefiles it means much more than making a bunch of C files to compile. the end user just use the compile part, but other environments (see the Gentoo build system) use more advanced Makefiles features. I just mention some: - CC, STRIP, LD, ... variables can override the default programs - DESTDIR is used as filesystem root for staged installs - test target is used to perform tests - CFLAGS, CXXFLAGS *must* be honored instead of hardcoding CFLAGS (like -march, -mcpu, -funroll-loops, -fomit-frame-pointer, -fpipe, ...) into Makefiles I wrote very few externs (notemono, tracker) and I should admit even my makefiles are broken and don't respect all of the above features writing a Makefile by hand is a PITA and much error-prone :| i don't think it's a big deal to have some basic makefile structure like that .. ok, well if we got any auto-tools specialist , who has a good solution now around here .. just my 0.02 Euro -- Federico Ferri ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list ¡El pueblo unido jamás será vencido! ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
