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

Hans-Christoph Steiner hans at eds.org
Wed Aug 9 22:13:39 CEST 2006


If you want to build a better build system, please go ahead and do  
it.  Just don't break anything in the process since thousands of  
people rely on it.  Please do not experiment on my code since trivial  
changes can cause problems which take hours to fix.  I already  
experienced this with the addition of pd-devel to the Pd-extended  
build system.  I had to spend hours debugging the changes in order to  
get Pd-extended building again.  That is also very annoying at the  
least.

The simple changes that you propose seem simple on the face, but have  
the possibility to wreak major havoc.  If you want to build another  
build system, then you should do what I did when building Pd- 
extended: I left everything in place without touching it and built  
the Pd-extended stuff alongside the existing build.

But yet again, it seems to me a massive waste of time to build Yet  
Another Build System.  How about instead making the existing one  
better?  For example, the Pd-extended build system would be much more  
flexible if there was a ./configure interface for it.  I think we  
should extend pd/src/configure.in to create a config.h and have  
everything build against that.

.hc

On Aug 9, 2006, at 4:21 AM, IOhannes m zmoelnig wrote:

> 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





More information about the Pd-dev mailing list