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 <[email protected] >>> <mailto:[email protected]>> 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 >> [email protected] >> http://lists.puredata.info/listinfo/pd-dev > > _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
