llvm-d

[Jens Mueller]

Moritz Maxeiner wrote:
> On Friday, 15 March 2013 at 21:18:09 UTC, Jens Mueller wrote:
> >Nice.
> >Can you make it compatible with Deimos
> >https://github.com/D-Programming-Deimos/?
> >
> >Jens
> 
> If by compatible you mean "can be used with":
> 
> I don't see anything that would prevent you from using llvm-d
> together
> with deimos bindings for other libraries.
> 
> If by compatible you mean "can be integrated into":
> 
> Afaik Deimos projects are linked with the libraries, instead of
> loading
> them at runtime. This is something I do not want because of the
> coff/omf
> hassle with optlink (on win32), which I can avoid by sidestepping
> the linker.

Deimos just provides a plain D interface for C libraries.
What do you mean?
You can do static or dynamic linking.
With dynamic linking it will be loaded at startup time by the loader.
But you can also load it at runtime using some system API which I assume
you do. I started ddl (http://jkm.github.com/ddl/ddl.html) which does
work with Deimos to some extent. A limiting factor is compilation speed.

> The next problem would be that afaik deimos is for pure C bindings
> only, but as mentioned under "Planned Features" on the github page I
> do plan on more or less recreating LLVM's OOP structure (as much as
> the C API exposes, anyway) in D around the C API as close to the
> original as sensible and feasible. Keeping two seperate projects for
> that seemed inefficient to me, even more so when one of them would
> only change for bug fixes (if any) and for new LLVM versions.

Even though I understand your arguments. Technically, they are different
projects. As you say built on LLVM's C API. One could use git submodules
to ease building the higher level API.

> Another pro for using runtime loading is that I can move the names
> of the libraries into llvm-d (which is what I did), so someone using
> llvm-d does not have to worry about library names, prefixes and
> suffixes. The most they have to do it to give -ldl to the linker on
> posix.

Very sensible. Yet this is something you want in general. ddl is able to
do this.

> These are the main reasons as to why I decided against making
> another deimos project in the first place and I can't think of a
> compelling reason for deviating from that decision right now, sorry.
> Correct me if I'm wrong, though, there's much about D I don't know
> yet.

In sum you want to load libraries at runtime and have a higher level
API. Both are fine. But I question that it is a good decision to do the
loading at runtime for each C library.

> If, however, there are enough people that *really* want a deimos
> version I could fork the project, strip out the shared lib stuff and
> change a few calls in the code generation to create extern functions
> instead of extern function pointers (The process is automated via
> CTFE, a mixin version of the "map" function and associative array
> enums) and that would be it, although I don't really see any real
> benefit to that (other than it being in deimos, which I don't think
> is a key factor now that we have dub with its package registry
> around).

I would use Deimos bindings. I even started one myself.
https://github.com/jkm/deimos-llvm/
But I cannot devote much time on it.

Jens