[LLVMdev] VMKit build problems; can't use LLVM3.4.2 ?

[Gaël Thomas]

Hi Brian,

The development of VMKit is a little bit stuck because we don't have
any contributor. Basically, I'm alone on the project and I don't have
any time for development (the engineers and PhD students that were
involved in the project are all gone).

As you can see, we only support LLVM 3.3. If you are interested in
helping porting VMKit for a newer version, I can help to explain how
VMKit is designed and to explain how the tricky parts of the code
work? Otherwise, I have started an implementation of VMKit for MCJIT
and a newer version of LLVM one year ago (branch mcjit), but I'm
unable to find any time to continue since january. But it means that I
know what we have to do to follow the last changes made in LLVM :)

So, if you are interested in contributing, just tell me.

See you,
Gaël





Le 21 juil. 2014 23:19, "Renato Golin" <renato.golin at linaro.org> a écrit :
>
> On 21 July 2014 21:33, Brian Faull <bfaull at cog-e.com> wrote:
> > Incidentally, this seems to be the same behavior/problem as reported on 20 January 2014 by neoedmund (http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-January/069558.html), which is solved by building using LLVM3.3 (no response seen).
>
> Hi Brian,
>
> It's common for some projects to attach themselves to a specific
> version of LLVM when the team doesn't have time to merge their code to
> trunk every other week, which can be very costly in the long term.
> However, any project that aims to be relevant in the LLVM community
> has to follow trunk, not a specific release, not even the current
> release. On projects whose aim is to present a proof-of-concept or to
> focus on a completely unrelated issue (VMKit, LLVMpipe), this seems to
> be the choice to stick to a release or even an SVN revision number.
> But for any compilation tool, it should never be.
>
> LLVM APIs do change considerably, even between a few commits apart.
> So, even if you support 3.5svn trunk, you can become obsolete in a
> matter of weeks. This dependency cannot be solved by LLVM supporting
> old APIs, or the code would have more legacy than features, and has to
> become a motto of the side projects themselves. Thus, unless VMKit
> developers are willing to follow trunk and have buildbots following
> the rest, it won't happen.
>
> Of course, as with any open source project, *you* could be the person
> to drive this, in case other VMKit developers are unwilling to take
> the extra work. :)
>
> cheers,
> --renato
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev