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