Hello Yigal,
Walter Bright wrote:
I've done the compiler-as-dll thing for the Digital Mars IDE. It has
some problems, though. The biggest is it's another executable to
test, doubling the testing process. It could be done as one
executable by making a shell that calls the dll, but those are just
inconvenient, harder to debug, and there's the old "dll hell" with
versions.
Instead, what you can do is simply dude up command line arguments,
spawn the command line compiler, and collect the result.
here's a thought: use DDL instead. no more "dll hell" :)
There's one thing ddl doesn't do that dll's/so's do. People seem to misunderstand
this aspect of it, as I did for awhile (until recently).
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.
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.
Thanks to Tom S. for clarifying this to me.
Whether or not this detail is significant to the idea of a compiler dll,
I don't know.
-JJR
