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, errordeveloper@gmail.com wrote:
On Tue, Nov 20, 2007 at 04:59:18PM +0100, mescalinum@gmail.com 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 autotoolsi 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
reckonapart 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!