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.
BTW - I'd actually like to get rid of the different translation methods if somehow possible. All that *should* be needed is really a -DPLUGIN (or whatever) so one actually has a choice about this at compile time. Unfortunately there a few tricky aspects involved which I couldn't quite figure out how to solve at the time Tim and I were working on this stuff. If somebody knows how to fix it please go ahead and send me the modifications.
byeBye "Smalltalk byeBye"
<primitive: 'exit' module: 'System'> self error: 'this should never be reached'! !
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?
Doesn't work on neither Mac or Win. That's because Mac/Win restrict the exported symbol by using either the #pragma export (Mac) or the EXPORT() macro (Win) to *only* export those specially marked functions. And 'exit' is none of these.
- Andreas
In message F539F53ECAF5D111B73D00805F65BAE68550F7@WDIGL003 "Raab, Andreas" Andreas.Raab@disney.com wrote:
[snip]
BTW - I'd actually like to get rid of the different translation methods if somehow possible. All that *should* be needed is really a -DPLUGIN (or whatever) so one actually has a choice about this at compile time. Unfortunately there a few tricky aspects involved which I couldn't quite figure out how to solve at the time Tim and I were working on this stuff. If somebody knows how to fix it please go ahead and send me the modifications.
I can actually think of a single small reason not to worry about this - since the file ought to go to a different place in order to make it utterly obvious to a 'make' whether it is for internal consumption or only for rubbing on sore spots, it probably doesn't matter much that the code is a little different. Of course, if anybody _can_ work out how t unify everything ok, then it might reduce the maintenance load a tad, which is always good.
tim
squeak-dev@lists.squeakfoundation.org