External building (was: Re: [PD] [lanbox] and [tcpclient])

Steffen stffn at dibidut.dk
Wed Jan 17 19:51:25 CET 2007


On 17/01/2007, at 18.58, IOhannes m zmoelnig wrote:

> Steffen wrote:
>>
>> On 17/01/2007, at 17.08, IOhannes m zmoelnig wrote:
>>
>>> the best version would be to provide a simple makefile
>>
>> so that people can checkout a single external from cvs plus the pd
>> section (or maybe just pd/src/m_ph.h ?), cd to the dir, run make?
>
> exactly.

Ok. Dare i ask, what prevents it? I'm guessing that of uniform cross- 
platform makefiles. Motivation:
* I just tried to build arraysize. so i checked it out, with pd. But  
the makefile shipped in didn't support my current platform plus the  
include path wasn't pointing to where it "should". So i had to  
changed it, and by inspiration from another makefile (i chose line3)  
i got it working. Not too much trouble.
* But passing the right path-var to make that was needed to build  
iemmatrix, fx, i don't think i'd worked out my self (i followed  
Kevins process due to curiosity on the topic).

To not reinvent sliced bread, how does that idea further differ from  
the build-system used by (or maybe more correct: made for) pd- 
extended? My guess is, not much, but it currently requires the  
packages section of cvs too, if i'm not wrong.

Im not sure where im getting at, except that i think it would be  
"nice" if it was "easy" to assemble/get just the settings of Pd one  
(the user) wants. There are a few "knobs to adjust" in this domain.  
To name some: millers version, pd-extended, devel, dd; pddp, or not;  
from none to more or all of the abstractions in cvs; from none to  
more or all of the externals in cvs, ...


> if you install pd differently (e.g. on debian with apt), you might get
> the m_pd.h file anyhow, probably as /usr/include/m_pd.h.
>
> i think no "standard" binary distribution of pd comes without this
> header file. (but i might be wrong).
> so there would be no need to checkout this file for _many_ cases  
> (there
> will be problems for more in-depth externals that need access to
> g_canvas.h,..; however most externals should be fine with just m_pd.h)

Ahh, i see. Thanks for the insight.

Best, Stefffen




More information about the Pd-list mailing list