-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
it seems like on the debian-stable-amd64 host of the build-farm, the Pd-headers have been uninstalled.
at least, Gem build#71 (2011-12-22 10:00:51) succeeded, whereas the next build#527 (2012-02-19 22:01:47) failed, because out of a sudden it cannot find the Pd-headers any more.
logging into the machine revealed, that the "pd-extended" package is installed, which provides headers in "/usr/include/pdextended" but: - - no compatibility header m_pd.h in /usr/include/ (like the puredata-dev package in debian does) - - `pkg-config --cflags pdextended` returns "-I/usr/local/include/pd", which does not exist at all. - - `pkg-config --cflags pd` fails as well as `pkg-config --cflags puredata`
would it be possible to have Pd-headers installed in a default location on _all_ auto-build machines? ideally, this would be somehow compatible with the header location on "ordinary" machines.
would it also be possible to not have to assume builds against Pd-extended?
fgmasdr IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-02-21 13:03, IOhannes m zmoelnig wrote:
- `pkg-config --cflags pdextended` returns "-I/usr/local/include/pd",
which does not exist at all.
- `pkg-config --cflags pd` fails as well as `pkg-config --cflags puredata`
which also leads to the questions: - - should both puredata-dev and pd-extended provide a "puredata.pc"? (like they do now for the "pd" executable); i don't know whether this is considered very bad style or not, but on my system, i have no .pc file that is handled by update-alternatives
- - 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....
gasdmr IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On Feb 21, 2012, at 7:08 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-02-21 13:03, IOhannes m zmoelnig wrote:
- `pkg-config --cflags pdextended` returns "-I/usr/local/include/pd",
which does not exist at all.
- `pkg-config --cflags pd` fails as well as `pkg-config --cflags puredata`
which also leads to the questions:
- should both puredata-dev and pd-extended provide a "puredata.pc"?
(like they do now for the "pd" executable); i don't know whether this is considered very bad style or not, but on my system, i have no .pc file that is handled by update-alternatives
- 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.
.hc
- ----------------------------------------------------------------------------
“We must become the change we want to see. - Mahatma Gandhi
-----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).
finally, the pdextended.pc pkg-config snippet is nevertheless broken.
fgmasdr IOhannes
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
I reinstalled 'puredata' on debian-stable-amd64, sorry about that, I don't know what happened there. The build systems are mean to have the Pd-vanilla headers installed.
I'm happy to install packages and put apps into /Applications. But in order to keep the systems clean for building, I will not put anything include /usr/local.
If you don't want to build against Pd-extended, then don't point to those headers. The Makefile template points to Pd-extended on Mac OS X and Windows because Pd-vanilla does not provide headers in the standard packages.
.hc
On Feb 21, 2012, at 7:03 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
it seems like on the debian-stable-amd64 host of the build-farm, the Pd-headers have been uninstalled.
at least, Gem build#71 (2011-12-22 10:00:51) succeeded, whereas the next build#527 (2012-02-19 22:01:47) failed, because out of a sudden it cannot find the Pd-headers any more.
logging into the machine revealed, that the "pd-extended" package is installed, which provides headers in "/usr/include/pdextended" but:
- no compatibility header m_pd.h in /usr/include/ (like the puredata-dev
package in debian does)
- `pkg-config --cflags pdextended` returns "-I/usr/local/include/pd",
which does not exist at all.
- `pkg-config --cflags pd` fails as well as `pkg-config --cflags puredata`
would it be possible to have Pd-headers installed in a default location on _all_ auto-build machines? ideally, this would be somehow compatible with the header location on "ordinary" machines.
would it also be possible to not have to assume builds against Pd-extended?
fgmasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9Dh/wACgkQkX2Xpv6ydvTQUACg3JGHJkUG7k5Bl2y+k/X92uJC z5IAniPXffHjoo/OjLtWvMCeHgkptAc/ =SbfI -----END PGP SIGNATURE-----
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-02-21 17:20, Hans-Christoph Steiner wrote:
I reinstalled 'puredata' on debian-stable-amd64, sorry about that, I don't know what happened there. The build systems are mean to have the Pd-vanilla headers installed.
thanks.
I'm happy to install packages and put apps into /Applications. But in order to keep the systems clean for building, I will not put anything include /usr/local.
if you refer to my complaint about "-I/usr/local/include/pd", then i need to clarify: the pd-extended installation installs a pkg-config snippet "pdextended.pc" which claims that - in order to compile e.g. an external - - you should add "-I/usr/local/include/pd" to the compiler flags. either you should fix pdextended.pc to contain (e.g.) "-I/usr/include", or remove it alltogether.
If you don't want to build against Pd-extended, then don't point to those headers. The Makefile template points to Pd-extended on Mac OS X and Windows because Pd-vanilla does not provide headers in the standard packages.
really? i remember that Pd-vanilla includes the full sources (including all headers) on both w32 and osx.
fmgasdr IOhannes
On Feb 21, 2012, at 11:33 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-02-21 17:20, Hans-Christoph Steiner wrote:
I reinstalled 'puredata' on debian-stable-amd64, sorry about that, I don't know what happened there. The build systems are mean to have the Pd-vanilla headers installed.
thanks.
I'm happy to install packages and put apps into /Applications. But in order to keep the systems clean for building, I will not put anything include /usr/local.
if you refer to my complaint about "-I/usr/local/include/pd", then i need to clarify: the pd-extended installation installs a pkg-config snippet "pdextended.pc" which claims that - in order to compile e.g. an external
- you should add "-I/usr/local/include/pd" to the compiler flags.
either you should fix pdextended.pc to contain (e.g.) "-I/usr/include", or remove it alltogether.
If you don't want to build against Pd-extended, then don't point to those headers. The Makefile template points to Pd-extended on Mac OS X and Windows because Pd-vanilla does not provide headers in the standard packages.
really? i remember that Pd-vanilla includes the full sources (including all headers) on both w32 and osx.
Pd-vanilla does provide the sources, but there are two issues:
- it does not include the include/pd/ subdir for headers
- on Mac OS X, the app has the version number in it, so using those for headers would make the Makefile dependent on a particular version of the Pd.app.
.hc
----------------------------------------------------------------------------
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-02-21 17:40, Hans-Christoph Steiner wrote:
Pd-vanilla does provide the sources, but there are two issues:
- it does not include the include/pd/ subdir for headers
i don't think this is an issue. externals have traditionally included "m_pd.h" rather than "pd/m_pd.h".
the suggested way is therefore, to add "-I/path/to/pd/headers" (e.g. "-I/usr/include/pd") to your CFLAGS and continue to use "m_pd.h"
- on Mac OS X, the app has the version number in it, so using those for headers would make the Makefile dependent on a particular version of the Pd.app.
true. i usually end up symlinking Pd-foo.bar.app to Pd.app...
fgmasdr IOhannes
On Feb 21, 2012, at 11:47 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-02-21 17:40, Hans-Christoph Steiner wrote:
Pd-vanilla does provide the sources, but there are two issues:
- it does not include the include/pd/ subdir for headers
i don't think this is an issue. externals have traditionally included "m_pd.h" rather than "pd/m_pd.h".
the suggested way is therefore, to add "-I/path/to/pd/headers" (e.g. "-I/usr/include/pd") to your CFLAGS and continue to use "m_pd.h"
It was definitely an issue, it was a pretty big headache to support the pd/ subdir in the Makefile template. I don't know the current status of things.
.hc
- on Mac OS X, the app has the version number in it, so using those for headers would make the Makefile dependent on a particular version of the Pd.app.
true. i usually end up symlinking Pd-foo.bar.app to Pd.app...
fgmasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9DyqQACgkQkX2Xpv6ydvSkugCfSqukJlrVjAGuSmSt5yXB6BKU h7oAmwZEwzZCAldEE3T+nLkGek3cpr5q =bKtW -----END PGP SIGNATURE-----
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
-
Hans-Christoph Steiner -
IOhannes m zmoelnig