[PD-dev] deb packages discussion

Hans-Christoph Steiner hans at at.or.at
Tue Sep 22 18:57:29 CEST 2009


On Sep 22, 2009, at 12:38 PM, IOhannes m zmoelnig wrote:

> Hans-Christoph Steiner wrote:
>>> 2) remove "m_pd.h" from externals and use <m_pd.h> (why do I need  
>>> to have PD source to compile my external? This should be installed  
>>> as any other library and linked with -l option; the m_pd.h should  
>>> be installed on /usr/include also)
>> sounds good
>
> hmm, Debian's official "pd" package already installs m_pd.h into / 
> usr/include/.
>
> personally i have long been voting for an official "pd.h" header,  
> rather than having the "m_" stuff lying around in my official  
> includes.
>
>
> for the PD_SRC, see below.


I also support just a 'pd.h' but there will be quite a bit of hassle  
with that.  The package could include a pd.h symlink to m_pd.h to  
start with.



>>> 3.1) Some build systems use a variable to point where is the pd  
>>> source. This is bizarre for me... let's make a pd shared library  
>>> and link to it...
>
> i don't see it so bizarre.
> there are two reasons for using a PD_SRC variable:
> - first: m_pd.h is not installed on your system and you still want  
> to compile the external. or you want to compile your external  
> against a version of Pd that is not the same as the one officially  
> installed.
> this is something a developer comes along quite often.
>
> - second, and this is more important: some externals depend on  
> "private" headers of Pd (s_stuff.h, m_imp.h); now one can argue that  
> it is bad style (though not necessarily "bizarre") to depend on  
> private headers - it's fine for me but for some interesting objects  
> there is no way around these private headers (personally, i think of  
> iemguts; or all of the loaders; or...);
> it would get bizarre to put the "s_stuff.h" into /usr/include :-)
>
> (ah yes, put everything into /usr/include/pd/ and then use pkg- 
> config to add /usr/include/pd to your path - this is a very standard  
> way for keeping /usr/include tidy and it is indeed quite similar to  
> what people are using the PD_SRC for)
>
>
> finally, your conclusion seems to be more bizarre than the problem.
> these PD_SRC variables point to the sources, not to the binaries.
> i don't see how making a shared library (which is a binary) will  
> help you at all here. (e.g. on linux i never "link" against Pd; but  
> on all platforms i do need the headers)
>
>> This is how it is done already on Windows.
>
> which is true and good, but (as pointed out above) unrelated to the  
> variable pointing to the Pd source.

>> - Windows and Mac OS X builds would remain as one big package  
>> unless there is a CPAN-type system developed for Pd.
>
> i agree (and honestly i don't think a CPAN-like system will happen  
> anytime soon).


It will happen as soon as someone does it.  :D  I don't think anyone  
objects to the idea, right?

.hc

----------------------------------------------------------------------------

I hate it when they say, "He gave his life for his country."  Nobody  
gives their life for anything.  We steal the lives of these kids.  - 
Admiral Gene LeRocque





More information about the Pd-dev mailing list