Compiler as dll

[Mike Parker]

grauzone wrote:

> 
> When it's a commercial program, the DLL plugin approach probably 
> wouldn't work anyway: in order to enable others to compile plugins, you 
> would need to expose your internal "headers" (D modules). Note that 

This is exactly what id software did with their Quake games. They 
provided an SDK, which included the headers and source files required to 
make mods. It was possible to use plain C to make DLLs or the QuakeC 
language they developed. This was before scripting languages became big 
in the game industry.

Personally, I would prefer a scripting language like Lua or Python over 
DLLs/object files for a plugin framework, no matter the application 
domain. The biggest reason is that it's easier to sandbox a script 
engine. But both approaches have their place.


> unlike in languages like C/C++, this would cause internal modules to be 
> exposed too, even if they are not strictly needed. What would you do to 
> avoid this? Maintain a separate set of import modules?
> 
> I think a purely extern(C) based interface would be better in these cases.
> 
> In fact, if you rely on the D ABI for dynamic linking, you'll probably 
> have the same trouble as with C++ dynamic linking. For example, BeOS had 
> to go through this to make sure their C++ based API maintains ABI 
> compatibility:
> 
> http://homepage.corbina.net/~maloff/holy-wars/fbc.html
> 
> I'm not sure if the D ABI improves the situation. At any rate, it 
> doesn't sound like a good idea.