[haskell-llvm] support for multiple LLVM versions in llvm-base

[Henning Thielemann]

On Sat, 18 May 2013, Nathan Howell wrote:

> The bigger issue is how many versions should be supported? Having one branch per version sounds great unless
> we're signing up to support 3+ versions (say... 3.1, 3.2, 3.3) and then patch management and testing will
> become a huge burden for all of us volunteering our time. Due to the nature of LLVM I'd be happy just
> officially supporting the latest released version on the master branch and taking patches for older branches
> as the community sees fit.

I'd prefer that way, too. If the package really contains only the plain 
interface to the LLVM-C API then there should not be much need for 
changing the Haskell API within one LLVM version.

> Do we want to support llvm-3.2 against llvm-base-3.1? Probably not. If the high level bindings take any
> updates from the low level bindings (versioned metadata, intrinsics, instructions) there will be tight
> coupling of versions or more #ifdef'd/stubbed code.

Since the 'llvm' package also must provide a fixed API depending only on 
its version, it will be hard to provide a constant API for different 
versions of llvm-base (using ifdef).

> And I'd prefer the ST and Wrapper modules to stay within llvm-base. It 
> has no additional build dependencies (just base and mtl) and they can be 
> quite useful for compiler developers and high-level bindings developers. 
> Don't import them if you don't need them.

'mtl' is a new dependency that was not needed for llvm-base before. And 
also: 'transformers' would be nicer, since it is simpler.
  Apart from that, the project structure currently becomes broken. We have 
three levels of interfaces in one repository, where the low and mid level 
are merged in one package. They reside in the 'base' directory and are 
affected by the configure procedure. In contrast to that, the high-level 
interface has no such directory. Since there are now multiple high-level 
interfaces it makes no sense to me to couple one of them with llvm-base. A 
clear structure for me would be the following one, where every package has 
its own repository (and thus allows simple tagging of versions and 
appropriate branching):

llvm-ffi (what is now llvm-base)
llvm-mid (what is now ST and Wrapper)
llvm-fd (what is now llvm, fd=functional dependencies)
llvm-tf (my variant of llvm using type families)
    names inspired by old monads-fd and monads-tf packages
llvm-typenat (the variant using type-level natural numbers)


Since cabal-install can install packages from multiple directories at once 
from the command-line it is also simple for developers to work with 
multiple packages:
  $ cabal install llvm-ffi/ llvm-mid/ llvm-fd/