morning Hans, morning list,
On 2008-11-18 21:18:41, Hans-Christoph Steiner hans@eds.org appears to have written:
On Nov 18, 2008, at 5:09 AM, Bryan Jurish wrote:
On 2008-11-18 02:32:57, Hans-Christoph Steiner hans@eds.org appears to have written:
Anyone know why moocow is dying on Fedora with this error: gcc -DHAVE_CONFIG_H [...] -c atom_alphabet.c In file included from atom_alphabet.c:28: ./atom_alphabet.h:32:18: error: gfsm.h: No such file or directory
... and the build process continues (without crashing) ...
... so aside from the (admittedly ugly, but otherwise inconsequential for the rest of the build process) errors, what's the problem? I could take the gfsm externals out of the list of 'moocow' build targets for pd-extended (since libgfsm isn't likely to be installed anywhere but on my own machines), but it ought to build successfully whenever libgfsm is installed, and it is freely available (LGPL, from me: http://www.ling.uni-potsdam.de/~moocow/projects/gfsm). I suppose I could also pack a local version of libgfsm into pd-gfsm and build it with the externals, or move it to sourceforge and use svn:externals, etc. etc. ... but that all seems like overkill to me... anyone have an opinion?
Hey,
Since libgfsm isn't included in any package management systems that I checked (Debian, Ubuntu, Fedora, Fink), I think it makes sense to include the libgfsm code in the pure-data SVN.
The weird thing is that AFAIK, libgfsm is not installed on any of the build farm machines, but this error only seems to happen on the Fedora 8 machine.
nope. same stuff happens elsewhere too, e.g. i386-debian-stable (http://autobuild.puredata.info/auto-build/2008-11-16/logs/2008-11-16_01.49.3...) line 17342:
gcc -DHAVE_CONFIG_H [...] -c atom_alphabet.c In file included from atom_alphabet.c:28: ./atom_alphabet.h:32:18: error: gfsm.h: No such file or directory
I'll want to experiment a bit with recursive autoconf/automake stuff before I can include libgfsm in the pd svn, but all things considered, I think you're right and that's the best solution for the time being. Optimally, pd-gfsm would always use its own version of libgfsm, to insulate against unforseen gfsm API changes... hmm...
marmosets, Bryan