What I tend to do is to put the Scheme source in a single directory, with a Makefile.
The Makefile dependency is -scm -> .o1
The rule deletes any .o1 (with rm -f to avoid errors on a clean build). Note that the issue
is the CHANGING of the target (Marc? is it possible to FORCE an output as .o?). Anyway,
forcing an output file to .o DOESN'T work:
A simple change, designed around Makefiles, instead of interactive use.
It should be possible to collect the .o (well, .o1) files into a library (and, using the unix/linux ar tool
it is). BUT, this is particularly annoying. Basically, assume that I have n .o1 files as
part of a library:
ar q new.o1 *.o1
should (and does) collect the object files into an archive, but we can't do
anything with it --
> (load "new.o1")
*** WARNING -- Could not find C function: "____20_new_2e_o1"
*** ERROR IN (console)@1.1 -- /export/home/fred/Projects/blib/new.o1: invalid ELF header
(load "new.o1")
1>
Gambit doesn't handle ar archives! (only ELF objects). This would be a simple enhancement
(and is easily butchered in, if load() is overriden). "ar t" will give the members, Each can be
easily extracted, and then loaded independently. I haven't yet butchered it though...
This change would seriously help ME :) because I can then easily distribute applications
(as the exe and an ar archive with the .o1 files, instead of 50 to 100 .o1 files).
For library delivery (in the Makefile) I build links from a ~~lib (or subdirectory) to the build
directory (filename#.scm and filename.o1 are linked, for access by gsi). I then manually
load the required components (usually via an include() in the source file).
All this works great for MY personal machine, but it is still a serious bear to try to distribute
binary applications.
So, to recap:
- gsi should be able to load ar archives as well as elf
- gsc should be able to compile to a fixed extension
- gsi shouldn't barf on an attempted load of ".o"
As an "advanced" feature, a gsc option to scan source, looking for (load) (##load)
(include) (##include) and building Makefile dependencies (I use a hack for this, using
sed). Since these can be built by (define-macro), it would be useful to have this done
by the compiler itself. This doesn't help for dynamically constructed (load), which
can be delayed until run-time, and my solution especially falls down in this case.
Doing the generation at compile-time would eliminate this problem for me.
- gsc option to generate dependencies for Makefiles
After these, we can examine other issues with "modules", proper static libraries,
and proper shared libraries -- but those are very complex.
Just my nickels worth.
FredW
On Thu, 2013-02-28 at 10:03 -0600, Jason Felice wrote: