[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