llvm-d

[Jens Mueller]

Moritz Maxeiner wrote:
> On Friday, 22 March 2013 at 08:34:11 UTC, Jens Mueller wrote:
> >Updated documentation
> >http://jkm.github.com/d-programming-language.org/deimos.html
> 
> NIice, but conforming to the following would create too much work
> for me:
> 
> "For each file a proper module declaration has to be provided"
> 
> Since files in llvm-c appear and dissappear across different LLVM
> versions, you would eventually have to keep files around that are
> many LLVM versions old.

Really. I thought the C API was expected to be more stable.
Also it's not yet clear how to manage multiple versions of the same
library in Deimos. But your feedback helps sharpening which issues
should be addressed by Deimos. Thanks.

> In llvm-d I use three files for the three main purposes: types,
> constants and functions. With ctfe having compatibility is trivial
> in that setup, with many more files that would be increasingly more
> work. Especially so since there are llvm-c headers with only few
> lines of code and creating an entire D module for that purpose seems
> wasteful and hurts maintainability or me.

I just did LLVM 3.1 and I get
$ find llvm -name '*.d' | xargs wc -l                                                                      0
    45 llvm/c/initialization.d
  2607 llvm/c/core.d
    97 llvm/c/object.d
    63 llvm/c/linktimeoptimizer.d
   523 llvm/c/enhanceddisassembly.d
    56 llvm/c/analysis.d
   136 llvm/c/executionengine.d
    38 llvm/c/transforms/vectorize.d
    72 llvm/c/transforms/ipo.d
    82 llvm/c/transforms/passmanagerbuilder.d
   125 llvm/c/transforms/scalar.d
   294 llvm/c/lto.d
    47 llvm/c/bitwriter.d
   166 llvm/c/disassembler.d
   115 llvm/c/targetmachine.d
    67 llvm/c/bitreader.d
   286 llvm/c/target.d
  4819 total

I assume you are referring to those files that are under 100 lines.

> "So far, each C header file was renamed to a D module. Next the
> contents of each module will be adjusted. In general following the
> advices from interfacing to c is recommended.
> 
> The D files should try to do as least modifications as possible to
> simplify updates of the C headers. This includes leaving comments
> intact."
> 
> Again, by cutting out everything but the actual code dealing with
> updates/new versions of LLVM becomes a lot easier. Dealing with the
> copyright issue can be done in compliance with LLVM's license by
> including LLVM's license note and copyright note in the
> documentation, in this case the README.md.
> 
> If I can make a deimos-llvm project the way I described it
> previously (by simply stripping out the shared lib code) I'll do it,
> because the changes would be few and maintaining both projects would
> be trivial; but if all deimos projects *have* to conform to these -
> in my case harmful - conventions, you might be better off with
> asking someone else to take over your deimos-llvm project.

I'm not the one to decide this. Probably this is the reason why I'm
writing the documentation because there is de facto no clear decision on
what needs to be done to warrant Deimos inclusion.
Assuming I can spend some time on deimos-llvm would you switch? I mean I
have 3.1. Adding 3.2 is possible. But I would need you to use it and
check that it works for your higher level API.

Jens