On Sat, 18 Jun 2011 23:33:29 -0400, Daniel Murphy
<yebbl...@nospamgmail.com> wrote:
"Jacob Carlborg" <d...@me.com> wrote in message
news:iti35g$2r4r$2...@digitalmars.com...
That seems cool. But, you would want to write the pluing in D and that's
not possible yet on all platforms? Or should everything be done with
extern(C), does that work?
Yeah, it won't be possible to do it all in D until we have .so's working
on
linux etc, which I think is a while off yet. Although this could be
worked
around by writing a small loader in c++ and using another process
(written
in D) to do the actual work. Maybe it would be easier to build dmd as a
shared lib (or a static lib) and just provide a different front...
My point is that the compiler can quite easily be modified to allow it to
pass pretty much anything (missing imports, pragma(lib), etc) to a build
tool, and it should be fairly straightforward for the build tool to pass
things back in (adding objects to the linker etc). This could allow
single
pass full compilation even when the libraries need to be fetched off the
internet. It could also allow seperate compilation of several source
files
at once, without having to re-do parsing+semantic each time. Can dmd
currently do this?
Most importantly it keeps knowledge about urls and downloading files
outside
the compiler, where IMO it does not belong.
Note the current proposal does exactly what you are looking for, but does
it via processes and command line instead of dlls. This opens up numerous
avenues of implementation (including re-using already existing utilities),
plus keeps it actually separated (i.e. a dll/so can easily corrupt the
memory of the application, whereas a separate process cannot).
-Steve
