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