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

Thomas Grill gr at grrrr.org
Wed Aug 9 12:37:43 CEST 2006


Hi all,
agreed. Personally, I rarely use the extended distro since i only need a 
few externals or library, and i don't like to be dependent on a large 
and probably hard to maintain build system.
I advocate simple Makefile files that are self-consistent and 
Makefile.extended or whatever for Hans' GUBS.
greetings,
Thomas

IOhannes m zmoelnig schrieb:
> David Merrill wrote:
>> Hello all,
>
> hi.
> 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 system.
>
>>
>> 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 folder_list.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:
>
> SO:
>
> 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 Makefile.buildsystem)
> 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 
> Makefile.simple.
> 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
> then
>  # cool, we can use the extended build system
>  make -f Makefile.extended
> else
>  # simple fallback
>  make -f Makefile.simple
> fi
>
> what do you think?
>
>
> mfg.adsr
> IOhannes
>
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
>
>

-- 
Thomas Grill
http://grrrr.org






More information about the Pd-dev mailing list