Henrik Gedenryd <Henrik.Gedenryd at lucs.lu.se> is widely believed to have written:

> > Arranging for the generated files to take note of a -DPLUGIN symbol to
> > compile themselves in "external plugin mode", for example, would be
> > perfect.  I could trivially rebuild the sqNamedPrims.h file in the
> > process, to reflect which plugins were "externalised".
> 
> It isn't clear to me whether you'all in this thread have noted that the
> Slang translator generates different C code for modules (and the VM hooks
> I'd suppose) depending on whether they are to be compiled with the VM or as
> separate plugin files. In other words, plugins generated for inclusion with
> the vm should not be compiled as standalone, and vice versa. Check out the
> changes inthe InterpreterPlugin class>>translation category (doh!
> obviously). 'locally' there means 'baked into the vm'. There are also way
> simple hooks for eg. leaving FFI out of the vm.
> 
> Someone made this remark before (Tim I think it was) and just ignore me if
> you already know this. However, it seems that this might be the solution to
> your problems.
I would think that it would be. Some cleanup is probably needed
somewhere, but basically modules can be generated as internal or
external and the generated code should go to a suitable place
automagically.

See InterpreterPlugin class> translate:doInline:locally: for details.

EXPORTed entries in modules generated for internal linking have entries
in sqNamedPrimitives.h and the others don't. They are linked with the
plugin stuff later.

As I've suggested several times before, a lot of this confusion could be
removed if someone could knock up a little tool that lists all the
translatable components and allows one to tick each one that is to be
made internal to the vm.

Currently you have to go to the unnacceptably enormous effort of editing
the Interpreter class>translate:doInlining:forBrowserPlugin: method to
remove any plugins you don't want internal, and then you have actually
evaluate some code (gasp!) to generate the other modules for external
usage. something like:-
{AsynchFilePlugin. FilePlugin. MIDIPlugin. SerialPlugin. SocketPlugin.
SoundPlugin. JoystickTabletPlugin. LargeIntegersPlugin} do: [:pl| pl
translate]
... for example. It's hard work I know, but think of the glory. This
snippet would generate directories (OK, folders for you MacMinions) with
the plugin code in them. If you move your platform specific files into
the right places, everything else should work. Make can work out what
plugins are internal/external trivially, sqNamedPrimiitves.h will be
correct anyway and all is well with the world. Which is why we wrote
the code to do it that way. You could of course read
http://minnow.cc.gatech.edu/squeak/811 and
http://minnow.cc.gatech.edu/squeak/1448 and find out what we documented
several months ago.


> 
> As for the inconsistent naming, these are probably remains from plugins
> older than the new pluginize paradigm. I think anyone should feel free to
> fix the naming.
Exactly. Andreas could probably think of consistent names for the B3D in
seconds and other authors likewise.
> 
> > Try this (replace 'System' with any plugin that you know exists and can be
> found
> > by the VM):
[snip]
> Ouch, this looks like a bug to me, but my Unix eyesight isn't 20/20. Tried
> it--does not work on the Mac. What about Win?
IIRC, only unix is this 'helpful'

tim

-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
"Bother," said Pooh, as Simon stole his Jet calender.