Add vendor/llvm

[winksaville]

Add LLVM as a submodule to zig so that LLVM maybe easily compiled and
different versions of LLVM can be tested as LLVM evolves.

The acutal submodule is vendo/llvm/src which defaults to LLVM-8.0.0 and
vendor/llvm contain a Makefile that allows it to be compiled as simply as
issuing a make -jN command. But also allows different versions to be
created by including Makefiles (aka .cfg files) which set variables that
control the build process.

Adds LLVM_LINK_STATIC as a cmake variable and suggests linking
vendor/llvm statically if LLVM isn't found or is the wrong version.
This avoids the need to set RPATH or LD_LIBRARY_PATH.

Modify README.md adding instructions for building LLVM using the
submodule. Also add a link to #build-llvm in README.md in error
messages in cmake/Findllvm.cmake.

[andrewrk]

Sorry, I'm not willing to support this.

[winksaville]

If I may ask, what is it you don't like?

[andrewrk]

It adds git submodules and it modifies/complicates the stage1 build for a near-nonexistent use case.

[winksaville]

It's not necessary to use submodules, I could change it. But just to mention, the developer does not need to use any submodule commands for regular use cases, such as compiling any of the provided configurations or even custom configurations. As for the overall use case, many platforms do not natively support LLVM 8.0.0 as the default so many developers will need to compile it. In addition, with the implementation I've provided it allows zig developers to easily test newer/different versions by just adding a ".cfg", just a makefile fragment, that is included by the actual Makefile. Or pass variables on the command line. Finally, if LLVM is installed natively or if manually downloading is desired, there are no changes to the workflow, it works exactly as before. I'm happy to answer any questions you may have and work on/discus any changes you'd like me to make.

…

On Thu, Apr 11, 2019, 1:14 PM Andrew Kelley ***@***.***> wrote: It adds git submodules and it modifies/complicates the stage1 build for a near-nonexistent use case. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2236 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA-hHKsdrpK9wMIB29h9oBFMJpBneF7Dks5vf21lgaJpZM4cnrkx> .

[andrewrk]

This is the supported process for building LLVM and clang from source: https://github.com/ziglang/zig/wiki/How-to-build-LLVM,-libclang,-and-liblld-from-source

This proposal adds another one, that I'm not convinced is better. It would just add confusion to the build process of Zig.

[winksaville]

I understand, but I believe this PR is easier than the current technique and less error prone because of its fewer steps. For example, last week when I downloaded the sources I was unable to verify the LLVM source file because it wasn't signed correctly for use by newer gpg versions used on Arch Linux. I did work with the Arch Release team and resolved the issue, but just an example. Also, the new technique requires less steps and we could streamline it further by adding a cmake command line variable or eventually automatically building LLVM when needed. I'll not push you further if you still wish to keep this closed. Thanks for considering it.

…

On Thu, Apr 11, 2019, 2:14 PM Andrew Kelley ***@***.***> wrote: This is the supported process for building LLVM and clang from source: https://github.com/ziglang/zig/wiki/How-to-build-LLVM,-libclang,-and-liblld-from-source This proposal adds another one, that I'm not convinced is better. It would just add confusion to the build process of Zig. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2236 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA-hHGwrlNlLHGiKYZ4qfLSrEzByMGC_ks5vf3t7gaJpZM4cnrkx> .

[andrewrk]

Related: #853