On 2015-11-25 09:49 AM, Hans-Christoph Steiner wrote:
If anyone wants to take over the pool of auto-build machines from me, there are 3 Debian VMs still up and running. I think the Windows one is still going too.
Looking at http://autobuild.puredata.info/auto-build/latest/ there are only three different packages produced in 2015:
Pd-0.44.0-extended-macosx106-x86_64.dmg 2015-04-04 09:29 39M Pd-0.44.0-extended-debian-wheezy-amd64.deb 2015-11-25 12:56 38M Pd-0.44.0-extended-chaos.dmg 2015-02-23 23:15 39M
At least the Debian wheezy package does not reflect the latest sourceforge changes, as I mentioned in my mail of Januari 5th.
In the planned/current decentralized setup of Pd external libraries, I am not sure which function an auto-build machine should fulfill. Anyone can fork from https://git.puredata.info/cgit/svn2git/ and make and build a library in 'deken/pd-lib-builder' compliant format. At some time I plan to do this for some unsupported but useful libraries.
From the Pd-extended codebase, it would be interesting to extract
patches from the pd-core code to make Pd-vanilla compliant with the Pd-extended help-patches. This could be based on the legendary patch-series, but I don't seem to be able to find them on sourceforge :-(.
.hc
Greetings,
Fred Jan
On Jan 5, 2015, at 8:17 PM, Fred Jan Kraan wrote:
Hi Martin,
Thanks for the reply,
On Sun, Jan 4, 2015 at 11:25 AM, Fred Jan Kraan <fjkraan@xs4all.nl mailto:fjkraan@xs4all.nl> wrote:
Hi,
After checking in some changes for cyclone, I hoped to see the results in the last remaining daily build, the Pd-0.44.0-extended-20150104-debian-wheezy-amd64.deb http://autobuild.puredata.info/auto-build/2015-01-04/Pd-0.44.0-extended-20150104-debian-wheezy-amd64.deb. But it appears it is no longer synced with the svn repository and builds the same code every day. To make sure the state of cyclone code is still ok, I checked out the repositry and recompiled. Cyclone is ok, but some other libraries fail:
...
loaders-pdlua: pdlua.c:45:17: fatal error: lua.h: No such file or directory
For the loaders-pdlua library I found it expects the lua.h in /usr/lib/lua/ while the actual directory is lua5.2.
Actually the Makefile in externals/loaders/pdlua specifies LUA_CFLAGS = -I/usr/include/lua and LUA_LIBS = -llua pdlua.c will compile against lua versions 5.1 and 5.2, it uses the LUA_VERSION_NUM from lua.h to determine which one. As it's possible to have both versions installed on a given machine, I don't know how the pd-extended build is supposed to decide which one to use. I'm guessing that the build farm machines use symlinks in /usr/include/lua and /usr/lib to point to the header and library.
There is a /usr/include/lua/lua.h which points to usr/include/lua5.1/lua.h and a /usr/bin/lua pointing to /usr/bin/lua5.1. Nothing lua in /usr/lib, that was just me being confused.
The lua.h is still not found, but I will look into it later. It is not essential, just nice to have it working or understand why it doesn't.
There are some differences between the versions which mean some of the examples won't run, as the "sandbox" only works in 5.1.
Martin
Fred Jan
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev