On Feb 21, 2012, at 11:26 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-02-21 17:15, Hans-Christoph Steiner wrote:
- should /usr/include/m_pd.h be handled likewise, using
update-alternatives? again, i'm not sure whether this is good style and cannot find such a thing on my system....
Pd-extended's headers are in /usr/include/pdextended only. If anything depends on them, that should be explicit, i.e. #include <pdextended/s_stuff.h>. This also allows for a parallel installation of the puredata headers, so no need to mix the two up.
hmm, but this will prevent the external to be buildable without having a full installation of pdextended (e.g. both the external-code and pd-extended are only available as a vcs-checkout) is this by design? while auto-building pd-extended, do you add an include-path that allows <pdextended/m_pd.h> to be included?
it also means, that you cannot make an external that builds for both pd-vanilla and pd-extended without some #ifdef trickery and user interaction (or some build-system (like autoconf) that detects whether pd and/or pd-extended is present).
So far, no one has needed these things. But they would be nice to have. And anything built for puredata will work for pdextended. That is the compatibility that I guarantee: one way compatibility from Pd-vanilla to Pd-extended.
finally, the pdextended.pc pkg-config snippet is nevertheless broken.
Could you file a bug report on that?
.hc
----------------------------------------------------------------------------
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra