# Using libgccjit?

The installed size of libgccjit varies from 18 MB (armhf) to 53 MB
(riscv64), with 37 MB for amd64.

That's quite large.  I wonder how much it could be stripped down if
you linked to it statically and didn't use all parts of it?

If I did use it to implement Zisp, I suppose I could offer the choice
of generating binaries that don't actually link to the full Zisp
runtime.

So, the final situation could be as follows, for example:

- The "meat" of Zisp would be a .so whose size is in the order of tens
  of MBs.

- A tiny wrapper executable linked to this .so would be the entry
  point to both an AOT compiler and a REPL for Zisp.

- Fully dynamic "lisp machine" applications (in the spirit of Emacs)
  that are both written in Zisp and support dynamic Zisp evaluation
  would have this .so as a runtime dependency, or need pretty much all
  of it to be compiled in.

- However, the Zisp AOT compiler could also output binaries (dynlibs
  and executables) that don't actually have zisp.so as a runtime
  dependency.

What if someone just wants to use a tiny script written in Zisp?  If
you want to use a tiny script written in Perl, Python, etc. you still
need the entire thing, so maybe it'd be acceptable for such scripts to
have full Zisp package as a runtime dependency.

Alternatively, Zisp could be split into a number of dynlibs that
implement different parts of it: zisp-gc.so, zisp-parser.so,
zisp-intrpr.so, zisp-comp.so, and so on, where zisp-comp.so would
probably be the largest.  There could be a "Zisp interpreter" package
that doesn't depend on that one.

Alternatively #2, there could be a ZispScript language that consists
of a strict subset of Zisp (e.g. no static typing, no eval) and an
interpreter for this language could simply be a program that happens
to be written in Zisp but doesn't depend on the full Zisp .so since it
doesn't use the native compiler.  However, what if someone wants to
write a program that *includes* a Zisp interpreter...

I think a combination of the two above ideas would be best: ZispScript
would be implemented by a library written in Zisp, zispscript.so,
which can be linked to if you want to write a program that can execute
ZispScript at runtime, and also the ZispScript package would come with
a little wrapper executable that invokes zispscript.so to interpret
scripts with a #!/usr/bin/zispscript shebang or such.