llvm dev - Mar 2017 - Shipping LLVM.dll for the C API with the Windows installer.

Hello list!

So I'm wondering if there is a will to ship a DLL with the C API
exported? LLVM currently ships with LTO.dll which has some C api
functions exported, made from the export file tools/lto/lto.exports,
so it would not be the first DLL LLVM shipped.

Currently I (and the users of my project[1]) are building it ourselves
using this script[2] derived from the LLVMSharp script[3]. Which adds
a extra long step for all users of ours and other projects like
LLVMSharp in order to use them.

The resulting LLVM.dll exports 809 functions and weighs in at around
18mb, so it would make the installer larger. There is also the cost of
maintaining a lists of export for the DLL, but hopefully we can use
the llvm-echo to test it on the windows nodes so any failure to add
new exports gets detected early.

Now for the bike-shed questions, do we call it LLVM-c.dll or just
LLVM.dll? Annotate all functions with a LLVM_EXPORT define or use a
llvm-c.exports file?

Thoughts and feedback welcome.

Cheers, Jakob.

[1] http://volt-lang.org
[2] https://github.com/VoltLang/GenLLVMDLLPy/blob/master/GenLLVMDLL.py
[3] https://github.com/Microsoft/LLVMSharp/blob/master/tools/GenLLVMDLL.ps1

On Thu, Mar 30, 2017 at 4:46 PM, Jakob Bornecrantz <wallbraker at
gmail.com> wrote:
> Hello list!
>
> So I'm wondering if there is a will to ship a DLL with the C API
> exported? LLVM currently ships with LTO.dll which has some C api
> functions exported, made from the export file tools/lto/lto.exports,
> so it would not be the first DLL LLVM shipped.
>
> Currently I (and the users of my project[1]) are building it ourselves
> using this script[2] derived from the LLVMSharp script[3]. Which adds
> a extra long step for all users of ours and other projects like
> LLVMSharp in order to use them.
>
> The resulting LLVM.dll exports 809 functions and weighs in at around
> 18mb, so it would make the installer larger. There is also the cost of
> maintaining a lists of export for the DLL, but hopefully we can use
> the llvm-echo to test it on the windows nodes so any failure to add
> new exports gets detected early.
>
> Now for the bike-shed questions, do we call it LLVM-c.dll or just
> LLVM.dll? Annotate all functions with a LLVM_EXPORT define or use a
> llvm-c.exports file?
>
> Thoughts and feedback welcome.
>
> Cheers, Jakob.
>
> [1] http://volt-lang.org
> [2] https://github.com/VoltLang/GenLLVMDLLPy/blob/master/GenLLVMDLL.py
> [3] https://github.com/Microsoft/LLVMSharp/blob/master/tools/GenLLVMDLL.ps1
Ping? Any thoughts?

What would be the best way to proceed? My cmake-fu is very weak so any
pointers here from those knowledgeable and stakeholders in the code
would be greatly appreciated.

Cheers, Jakob.

We already half-have this, the LLVM_BUILD_LLVM_C_DYLIB cmake option builds
a shared object which exports the llvm-c interface but it only works on
Darwin.

tools/llvm-shlib/CMakeLists.txt is where how this is done is defined, and it
looks like it does it by:
 * build LLVM.so
 * use nm+awk+sed to pick out the symbols starting with LLVM
 * build LLVM-C.so using a -reexport_library linker option

I'm thinking that maybe we could make this not-darwin-specific by making
use of utils/extract_symbols.py:
 * edit extract_symbols.py to add a --only_unmangled option (or maybe
   --only_prefix=LLVM or something like that)
 * on non-darwin use that instead of the existing command to get the
   symbols to export (or: make extract_symbols.py work on Darwin)
 * instead of building LLVM-C.so from LLVM.so using this -reexport_library
   option, instead build LLVM-C.so from the same libraries that LLVM.so
   is built from
 (where I use .so above, it also applies to .dll)

John
> -----Original Message-----
> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
> Jakob Bornecrantz via llvm-dev
> Sent: 05 April 2017 12:51
> To: llvm-dev
> Subject: Re: [llvm-dev] Shipping LLVM.dll for the C API with the Windows
> installer.
> 
> On Thu, Mar 30, 2017 at 4:46 PM, Jakob Bornecrantz
> <wallbraker at gmail.com> wrote:
> > Hello list!
> >
> > So I'm wondering if there is a will to ship a DLL with the C API
> > exported? LLVM currently ships with LTO.dll which has some C api
> > functions exported, made from the export file tools/lto/lto.exports,
> > so it would not be the first DLL LLVM shipped.
> >
> > Currently I (and the users of my project[1]) are building it ourselves
> > using this script[2] derived from the LLVMSharp script[3]. Which adds
> > a extra long step for all users of ours and other projects like
> > LLVMSharp in order to use them.
> >
> > The resulting LLVM.dll exports 809 functions and weighs in at around
> > 18mb, so it would make the installer larger. There is also the cost of
> > maintaining a lists of export for the DLL, but hopefully we can use
> > the llvm-echo to test it on the windows nodes so any failure to add
> > new exports gets detected early.
> >
> > Now for the bike-shed questions, do we call it LLVM-c.dll or just
> > LLVM.dll? Annotate all functions with a LLVM_EXPORT define or use a
> > llvm-c.exports file?
> >
> > Thoughts and feedback welcome.
> >
> > Cheers, Jakob.
> >
> > [1] http://volt-lang.org
> > [2] https://github.com/VoltLang/GenLLVMDLLPy/blob/master/GenLLVMDLL.py
> > [3]
> https://github.com/Microsoft/LLVMSharp/blob/master/tools/GenLLVMDLL.ps1
> 
> Ping? Any thoughts?
> 
> What would be the best way to proceed? My cmake-fu is very weak so any
> pointers here from those knowledgeable and stakeholders in the code
> would be greatly appreciated.
> 
> Cheers, Jakob.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev