Compiler as dll

[Nick Sabalausky]

"grauzone" <none at example.net> wrote in message 
news:glpha0$dg3$1 at digitalmars.com...
> Alexander Pánek wrote:
>> 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?
>
> But why do you want them in the first place? For Open Source projects, 
> this seems to be completely pointless to me.
>

With runtime-pluggables:

1. A program can download, install and use a plugin without the program 
needing to be restarted.

2. Out of all existing plugins, any arbitrary subset can be enabled without 
requiring an exponential number of pre-compiled executables, without 
requiring the user (or the program itself) to recompile anything, and 
without needing to install any build tools on the user's system.