[haskell-llvm] llvm-base vs. llvm-general

Scott West scott.west at inf.ethz.ch
Sun Jan 19 09:27:35 GMT 2014


Hello Henning,

(Aside)
Configuration of LLVM is fragile for all bindings because they produce
"broken" configuration utilities. llvm-config will only talk about the
modules that were told to be built, but these modules (in the case of an
autotools build) do not correspond to the shared library that is
actually built (which is called libLLVM-$(version).so . The LLVM shared
library build actually builds separate .so files for each module so I
believe they actually correspond properly to what llvm-config
indicates. There is a bit of a schism in the LLVM build system, they are
moving towards a CMake build, but *very* slowly (only recently did they
get the ability to build their doxygen documentation with CMake), and
right now it's a bit of a choice between having things like ocaml
bindings, or getting a llvm-config that actually reflects the libraries
that were built.

(Back on topic)
If you recall, there was an earlier thread were we also had a discussion
(http://projects.haskell.org/pipermail/haskell-llvm/2013-August/000390.html)
about how the dependencies could be structured to bring the packages
under one roof. The conversation petered out, but there weren't any
large disagreements on how to move forward, I just didn't the time to
push for any particular design. I still feel its important to get this
right though, as we have to find a solution that everyone is our small
community can live with. Being a small community it doesn't seem
efficient to divide our time maintaining two packages when they should
be able to share much of the same code and have everyone still get the
functionality that they need.

I remember you had reservations about the use/portability of TH in
llvm-general, is this a non-starter for you, or can you live with it?

Regards,
Scott


schlepptop at henning-thielemann.de writes:

> Am 19.01.2014 00:35, schrieb Carter Schonwald:
>
>> henning, I understand your stance, what i'm saying is I am happy to
>> evaluate porting the llvm api to sit on top of llvm-general. If it was
>> api compatible, would that be a satisfactory type safebackend?
>
> Currently I don't use 'llvm' as is, but 'llvm-tf' which is 'llvm' ported 
> to type families. I like 'llvm-base' as it is, except the fragile 
> configure procedure. But the configure procedure of llvm-general also 
> looks complicated. For me the best option is to keep llvm-base going.
>
>
> _______________________________________________
> Haskell-llvm mailing list
> Haskell-llvm at projects.haskell.org
> http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-llvm




More information about the Haskell-llvm mailing list