Hi Richard,
> However, I have one proposal regarding the LIBDIR mechanism. I don't
> like the way it is hard-coded into the sfront executable. [...]
Yes, I understand -- I'll try to add the
const char *get_sfront_libpath(char *errmsg /* = NULL*/);
into an upcoming release.
However, basically, I think the long-term solution is
to have part of the sfront compilation process being sucking up
all the lib/*/*.{c,h} files, and storing them in the sfront executable
in a compressed form. This would really result in just one executable
for sfront doing the whole job, that would require no environment
variables or knowledge of where its installed. This would be done
in tandem with removing the manual changes to sfront/src/control.c
and sfront/src/audio.c that library writers have to make as well.
I'd estimate about 60% of the code that ends up in a sa.c file
comes from libraries that are already embedded in the sfront
executable in this manner, check out the sfront/src/corecode.c and
sfront/src/wtparse.c files to see the hand-coded core opcode and
wavetable libraries embedded in C strings. Basically, the
sfront/lib/* files are those that never reference SAOL program
variables by name ...
Conceptually, this looks fairly easy to implement ... you'd
probably want to keep the get_sfront_libpath() mechanism
around also, though, so new libraries can be added without
picking up a new binary ...
--jl
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:15:26 EDT