Compiler as dll

[Alexander Pánek]

grauzone wrote:
> John Reimer wrote:
>> ddl does not work for memory sharing like normal dll's, where multiple 
>> applications have access to a single dll at runtime.  It appears that 
>> such support would be quite difficult to implement and moves in the 
>> direction of operating system features.
> 
> Couldn't this be achieved by simply mmap()-ing the file contents into 
> memory? mmap() normally shared the memory pages with other processes.
> 
> Of course, this wouldn't work if the code both isn't position 
> independent, and needs to be relocated to a different base address. But 
> that's also the case with operating system supported dynamic shared 
> objects.
> 
>> It does do runtime linking, however, which is extremely useful for 
>> certain situations... specifically any sort of application that needs 
>> a plugin architecture for D (ie.. it can link with libraries and 
>> object files at runtime) that is gc and exception friendly.  
> 
> I never understood why this is needed. Can't they simply compile the 
> plugins into the main program?

Well, compiling them directly into the main program kinda defeats the 
purpose of runtime-pluggable plugins, wouldn’t it?

> 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 
> 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?

Make use of .di files. You don’t have to distribute code.