Re: How to solve this import in an eval problem?

[Peter Bex]

On Mon, Nov 11, 2019 at 10:43:44PM -0700, Matt Welland wrote:
> I'm working toward porting my various projects to chicken 5 and for one
> project I first want to convert a bunch of compilation units to modules.
> This has mostly gone well but I'm stuck on exposing module code in an eval.
> Without modules this worked great as everything was visible to the eval.
> 
> It actually works ok if I run in the directory where the .import.scm file
> lives but fails when the exe is run from a different directory.

Hi Matt,

That makes sense; to import a module at run-time, that module needs to be
available, so it must be in the module search path (which is the chicken lib
dir and the current directory).

I've tried your test case, and tweaked it a bit to make it work on C5.
The way to make this work without requiring the module to be in the search
path would be to bake it into the executable.

To do that, you can compile the import library into a .o file and include
it in the final binary, much like you did with the main code of a.scm.

I added this recipe to the Makefile:

a.import.o: a.import.scm a.o
        csc -unit a.import -c a.import.scm -o $*.o

And then I added (declare (uses a.import)) to the top of c.scm to ensure
that the import library's toplevel gets invoked.  Also, add dependencies
as needed for Make to do its thing.

This way, the module registration is also done inside the executable, and
because the module is already known, the run-time import won't cause it to
be looked up at runtime.

Cheers,
Peter

signature.asc
Description: PGP signature