That works. Thanks!
On Tue, Nov 12, 2019, 1:11 AM Peter Bex wrote:
> 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
>