Yes, that sounds like a good long-term solution; and I like 'both-and'
systems too.
I'm already wondering what I would need to do to get sfront to make a
version of sa.c that I can compile to run on my SHARC EZ-KIT - there
must be any number of custom versions possible.
Richard
John Lazzaro wrote:
>
> 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
-- Test your DAW with my Soundcard Attrition Page! http://wkweb5.cableinet.co.uk/rwd (LU: 6th July 1999) CDP: http://www.bath.ac.uk/~masjpf/CDP/CDP.htm (LU: 14th June 1999)
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:15:27 EDT