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
_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
