[gambit-list] Build tool, directory structure
fred.weigel at zylog.ca
Fri Mar 1 14:13:36 EST 2013
Jason (and Marc)
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:
[fred at dejah blib]$ cp amb.o1 amb.o
[fred at dejah blib]$ gsi
> (load "amb.o")
*** ERROR IN "amb.o"@1.5 -- Illegal character: #\x02
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
anything with it --
[fred at dejah blib]$ gsi
> (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
Gambit doesn't handle ar archives! (only ELF objects). This would be a
(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
This change would seriously help ME :) because I can then easily
(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
All this works great for MY personal machine, but it is still a serious
bear to try to distribute
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
(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
can be delayed until run-time, and my solution especially falls down in
Doing the generation at compile-time would eliminate this problem for
- gsc option to generate dependencies for Makefiles
After these, we can examine other issues with "modules", proper static
and proper shared libraries -- but those are very complex.
Just my nickels worth.
On Thu, 2013-02-28 at 10:03 -0600, Jason Felice wrote:
> Gambit-list mailing list
> Gambit-list at iro.umontreal.ca
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gambit-list