[PD-dev] deb packages discussion

[IOhannes m zmoelnig]

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.


> 
>> 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).

fmgasdr
IOhannes


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20090922/e89e6f03/attachment.bin>