ORC jit example (was: refs to LLVM consultants)

Any thoughts of including lli in the nightly snapshot/package builds, for
those of us embedding the JIT? The setup for a first build from source
looks involved...

Any thoughts of including lli in the nightly snapshot/package builds, for those of us embedding the JIT?

+1. I’ve wanted this (and llc) several times recently for debugging IR issues on Windows.

The Windows snapshots are targeted at users who want to try out an
LLVM toolchain on Windows rather than LLVM developers, so they don't
include all the tools such as opt, llc, lli etc, or libraries.

We experimented with shipping full builds, but they were much bigger.

If you're doing LLVM development on Windows, you'll probably want to
build your own.

Bigger than the 3.6 release builds? Why would nightlies have less
functionality than releases? Shouldn't a reduced build for tire kickers be
based on a proven release?

I'm simply a client of the new ORC library; I just need binaries.

The Windows snapshots are targeted at users who want to try out an
LLVM toolchain on Windows rather than LLVM developers, so they don't
include all the tools such as opt, llc, lli etc, or libraries.

We experimented with shipping full builds, but they were much bigger.

Bigger than the 3.6 release builds? Why would nightlies have less
functionality than releases? Shouldn't a reduced build for tire kickers be
based on a proven release?

The snapshots and the Win release are built the same way. Neither
contain libraries or development tools; they're both suitable for use
as a tool-chain, but not for consuming LLVM as a library.

I'm simply a client of the new ORC library; I just need binaries.

The LLVM build doesn't have a good shared library story on Windows
yet. See e.g. this thread:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/084142.html

A static library (for lib/ExecutionEngine/* in my case) would be preferable
to a DLL.

Those are generally useful components and wouldn't add much to the release.