Package Base Details: llvm-git

Git Clone URL: (read-only, click to copy)
Keywords: clang git lld lldb llvm polly
Submitter: yurikoles
Maintainer: Lone_Wolf
Last Packager: Lone_Wolf
Votes: 110
Popularity: 0.012737
First Submitted: 2018-12-05 13:56
Last Updated: 2020-01-26 13:32

Pinned Comments

Lone_Wolf commented on 2019-04-12 20:41

I've looked good at clang-trunk , llvm-svn, repo llvm/clang packages and think this package is now on route to become a worthy successor to llvm-svn .

  • llvm-libs-git holds the runtime libraries.

    It conflicts with the repo llvm-libs package. This is the only way to make sure the llvm linker from git is used, and that's needed for a full dev environment.

  • llvm-git

    has llvm , clang, compiler-rt, ocaml & python bindings, polly , lld , lldb .

The Package now uses a new environment variable to make ninja behave, NINJAFLAGS. If you want to use it adjust the snippet below to your desired values and add it to makepkg.conf.

Incase you are satisfied with ninja defaults you don't need to do anything.

# Add to makepkg.conf
# limit ninja to 20 jobs
# requires special code in PKGBUILD
# see ninja --help for additonal options

The check() function fails rather often, but I do suggest to build with them. If build fails due to test failure you can add --nocheck to skip the tests.

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 ... Next › Last »

Lone_Wolf commented on 2019-04-29 15:09

llvm and co provides will be returned in next upload, though with a specfic version.

Lone_Wolf commented on 2019-04-29 11:39

That is a good idea, lahwaacz. I'll switch to that method.

lahwaacz commented on 2019-04-28 14:08

You can use any other variable name, e.g. $NINJAFLAGS, and set it in your makepkg.conf as needed. People who want it can set it as well and nothing changes for people who are content with the defaults.

Lone_Wolf commented on 2019-04-28 13:16

Lahwaacz, I agree completely with that assessment. Unfortunately ninja does not support any method to set flags externally. no environment vars, no config files, only commandline. In my opinion Ninja default values may fit a dedicated buildserver, but are broken for all other usecases.

Using makeflags to get ninja to behave is imo the lesser evil. 
looks like a good solution, but no idea when/if that will be availalble.

lahwaacz commented on 2019-04-28 12:17

Using $MAKEFLAGS for ninja is not a good idea because it does not have the same flags as make and even those that look the same may behave differently (e.g. ninja's -k takes an argument, whereas make's doesn't). Anybody who has something else than -j or -l in $MAKEFLAGS will complain.

Lone_Wolf commented on 2019-04-28 12:02

A wrapper won't work as ninja is also called directly in sub-commands.

setting MAKEFLAGS is a good idea if you ever use Make to build stuff, as make defaults to -j1 if makeflags aren't set.

If you prefer to keep makeflags unset and don't mind ninja (potentially) overburdening your processor and memory , use this in the PKGBUILD :

    if [[ ! $MAKEFLAGS ]]; then
        ninja all ocaml_doc
        ninja "$MAKEFLAGS" all ocaml_doc

That will be in next version of the package i'll upload , probably monday.

SolarAquarion commented on 2019-04-27 13:23

Isn't an alternative is to simply create a wrapper in prepare which calls /usr/bin/ninja or do i need to set $MAKEFLAGS

Lone_Wolf commented on 2019-04-27 13:11

Confirmed, but leaving that out leads to overburdening of systems and memory swapping due to ninja (badly chosen imo) defaults.


SolarAquarion commented on 2019-04-26 13:35

i think you should delete $MAKEFLAGS from the build process because if you don't have $MAKEFLAGS enabled it fails

QuartzDragon commented on 2019-04-23 03:46

Bug report for broken Clang: