[gambit-list] Build tool, directory structure

Fred Weigel 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
Gambit v4.6.6

> (load "amb.o")
*** ERROR IN "amb.o"@1.5 -- Illegal character: #\x02
1> 

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 --

[fred at dejah blib]$ gsi
Gambit v4.6.6

> (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: 




> _______________________________________________
> Gambit-list mailing list
> Gambit-list at iro.umontreal.ca
> https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20130301/3314d520/attachment.htm>


More information about the Gambit-list mailing list