[plt-scheme] embedding & modules problem

At Thu, 30 Apr 2009 10:08:50 +0100, Dave Griffiths wrote:
> A related question. Is there a way I can conditionally require from
> modules coming from different sources like this? (eq a dynamic linked
> extension vs in-source definition) I should explain what I'm trying to
> do, as it's probably easier.
> 
> I'm creating a version of fluxus where all the binary extensions,
> required plt scheme code and libmzscheme (and other libs) are embedded
> and statically linked into the application binary - in order that I can
> make an easily distributable version for use for a multiplatform game
> (with all livecoding features still present btw, as a potential hook to
> get people into scheme).
> 
> I have all this working, except for a couple of lines in scheme, where I
> require the binary extensions using e.g. (require "fluxus-engine.ss")
> while in the static linked version I need to call (require
> 'fluxus-engine) instead - as I am using scheme_primitive_module to
> create the module directly in the environment from C++. 
> 
> I can change these lines by hand, but is there a way to detect the
> difference and do the right thing ('if' won't work, but maybe a macro? I
> could also get the build script to choose and rename the correct
> module .ss file :/ ) 

I think I'd try to give the module the same name in both cases:

 * You could set `current-module-declare-name' before calling
   scheme_primitive_module() to give the created module the name path
   as "fluxus-engine.ss". (The docs for scheme_primitive_module() refer
   to the old parameter, so I'll fix the docs.)

 * Another possibility is to extend the module name resolver in the
   embedding application to redirect "fluxus-engine.ss" to
   'fluxus-engine.

I guess that a macro could check for a "USE_EMBEDDED_FLUXUS"
environment variable and expand to `(require 'fluxus-engine)' if it's
set or `(require "fluxus-engine.ss")' if not. I'd do that as a last
resort, though, because it would make the bytecode of the enclosing
module sensitive to an environment variable, which can interfere with
tools you might one day apply to the modules.