[foo-devel] next foo release deferred

[martin r. <fo...@ru...>]

dear foo developers,

i spent quite the whole day today to prepare the release of
foo-0.0.3.

i completely restructured the source tree in preparation for the new
internal structure of foo (core/modules) while leaving the actual
structure as is for now.

i started to integrate a build system using gnustep-make, which is
quite sophisticated and easy to handle.

unfortunetaly, it doesn't create libtool compliant libraries
(.la/.a/.so), just normal .so files, but the new elk seems to rely on
the libtool ones.  after some few modifications on elk i am able to
load the libfoo.so file, but the automatic initialization
(elk_init_xxx) doesn't take place, though there is definitely a symbol
table in the library.

for today i'm about to give up.  for the next steps, i am considering
using the normal autotools build system instead of gnustep-make to
have libtool support, but this is quite much work and i don't how this
is handled on mac os x (and how well it integrates with gnustep, but
we could "steal" from the gnustep-gui code, which contains most of the
necessary macros to figure out the particular gnustep installation).
anyway, supercollider for example uses autotools on linux and
projectbuilder on mac, though this leads to sync problems when
maintaining two independent build systems separately.  best thing
would a common system for both mac and linux, and since foo is a
command line tool, i think autotools are acceptable even on mac (when
working).

on the other hand, i think there must be something wrong with elks
initialization code, since it should allow loading of .so files as
well.  i will try to figure out what is happening there.

unfortunetaly i have to do a lot of urgent homeworks towards the end
of the semester, thus i can't proceed right now with foo.  gerhard, if
you want to build it, you may try it with the current versions
released at sourceforge, but there is some handwork to do, for example
the scm-tree has to be copied to /usr/share/foo or whatever by
hand...  and it's not very suited for development since some things
changed in my local copy, but it's still in a mess.

if you have the time, you could try to build the current elk (3.99.6)
from http://sam.zoy.org/projects/elk/ on mac os x.  i had no luck in
the studio, because ./configure died at the very beginning.  i found
that gcc is called with an illegal option, which happens on other
software packages, too.  i guess we could blame it on a broken
installation on the studio computer.

if elk compiles and runs on mac, we know that autotools seem to work
(though not with objc) and if the elk_init_ magic is working on mac,
too.  this could give some hints how to go on.

all the best for now!

martin