[PD-dev] Re: [PD] building HID from the CVS, errors

IOhannes m zmoelnig zmoelnig at iem.at
Wed Aug 9 10:21:04 CEST 2006

David Merrill wrote:
> Hello all,

i am redirecting this to pd-dev, since i hope this mail will lead to 
some further dev-specific discussion and hopefully to some usable build 

> Has anyone else had a problem trying to compile an external from the CVS 
> source? I just checked out the externals dir from CVS, and wanted to 
> compile the latest [hid], so after reading the README in the hid 
> directory, I typed:
>  >make INCLUDE=/usr/lib/pd/src PDEXECUTABLE=/usr/bin/pd
> ..and got the following:
> --paste--
> --end paste--
> Why would the build want a /sigpack, and /zexy directory? And am I 
> missing a Makefile.buildlayout file?

to compile hid (and i guess, any of hans's externals) you need the 
entire pd-cvs (at the very least you need the "packages" module) 
downloaded from sourceforge.
i agree that this is _very annoying_ at the least.

my solution to compile something as simple as [folder_list] was to NOT 
use hcs's build system at all (i really just wanted to have to download 
not more than 1MB to get this single object), but instead compile the 
object with:
 > gcc -g -O2 -I. -DPD -fPIC -export_dynamic -shared -o folder_list.o -c 
 > gcc -export_dynamic -shared -o folder_list.pd_linux folder_list.o -lm -lc

you might try something similar with hid, although things are a bit more 
complicated here.

that's basically the answer to your question, the rest is what i draw as 
a conclusion:


i see the need for a "grand unified build system" for things like 
pd-extended. but i am not totally sure, whether everything should be 
sacrificed to pd-extended.
naturally, hans has the right to do anything with his code, including 
forcing anyone trying to build the sources from his part of the 
repository with any build system he likes.
nevertheless, i would recommend a system that would make the best of the 
two worlds: be able to take advantage of the general pd-extended build 
system and (at the users option) be able to not have to use the 
pd-extended build system (probably at the cost of having to do some 
manual configuration if the maintainer doesn't want to maintain to 
configuration systems)

the simplest solution that comes to my mind is, that one of the 2 
systems uses a differently named makefile.
since pd-extended's build-system is more likely to be called from a 
parent makefile (because somebody wants to build the entire pd-extended 
build-system), i suggest to name this Makefile.extended (or 
anybody wishing to build using the extended build system, would call 
"make -f Makefile.extended".
other users would just do a "make".

a more sophisticated method would use a Makefile.extended and a 
the ordinary "Makefile" would first check for the existence of the 
extended build-system and if present, it would use Makefile.extended, 
else it would use Makefile.simple.

if test -e ../../packages/Makefile.buildlayout
  # cool, we can use the extended build system
  make -f Makefile.extended
  # simple fallback
  make -f Makefile.simple

what do you think?


More information about the Pd-dev mailing list