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

[Nathan Howell]

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.

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.

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.

thanks,
-n



On Sat, May 18, 2013 at 5:39 AM, Henning Thielemann <
lemming at henning-thielemann.de> wrote:

>
> Currently there are a lot of CPP switches that conditionally import
> functions from LLVM. However that means that the same version of llvm-base
> has a different API depending on the LLVM version it was compiled with.
> This does not work. Every version of a Cabal package must have a defined
> API, independend from Cabal flags and other configurations:
>   http://www.haskell.org/**haskellwiki/Cabal/Developer-**
> FAQ#Enabling_additional_**features_via_Cabal_flags<http://www.haskell.org/haskellwiki/Cabal/Developer-FAQ#Enabling_additional_features_via_Cabal_flags>
>
> The correct way to go is to let llvm-base-3.0 export the interface of
> LLVM-3.0, llvm-base-3.1 export the interface of LLVM-3.1 and so on. It
> would be ok to implement the interface of llvm-base-3.0 with LLVM-3.1,
> though, if this works.
>
> This also stresses my point, that the ST (and Wrapper) code should be in a
> separate package since I think that their interfaces are independent from
> the LLVM API. The new package could still accept a range of versions of
> llvm-base.
>
> ______________________________**_________________
> Haskell-llvm mailing list
> Haskell-llvm at projects.haskell.**org <Haskell-llvm at projects.haskell.org>
> http://projects.haskell.org/**cgi-bin/mailman/listinfo/**haskell-llvm<http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-llvm>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://projects.haskell.org/pipermail/haskell-llvm/attachments/20130518/371070fa/attachment.htm>