[PD-dev] moocow/libgfsm error on Fedora

[Bryan Jurish]

morning Hans, morning list,

On 2008-11-18 21:18:41, Hans-Christoph Steiner <hans at 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 at 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.38_linux_debian-stable-i386_pd-extended_run-automated-builder.txt)
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

-- 
Bryan Jurish                           "There is *always* one more bug."
jurish at ling.uni-potsdam.de      -Lubarsky's Law of Cybernetic Entomology