Package Base Details: llvm-git

Git Clone URL: https://aur.archlinux.org/llvm-git.git (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.055290
First Submitted: 2018-12-05 13:56
Last Updated: 2019-11-18 14:13

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. I understand how older llvm libs repo packages do it, not sure yet if i agree with the approach.

  • llvm-git

    has llvm , clang, compiler-rt, ocaml & python bindings, polly , lld , lldb . The provides for llvm-svn have been re-added to allow others maintainers to update their packages.


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
NINJAFLAGS="-j20"

llvm check now works, clang check however fails. I suggest to test without nocheck first, if build fails due to test failure add--nocheck .

Latest Comments

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

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.

https://github.com/ninja-build/ninja/issues/1482 
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
    else
        ninja "$MAKEFLAGS" all ocaml_doc
    fi

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.

See https://bbs.archlinux.org/viewtopic.php?id=246007

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:

https://bugs.llvm.org/show_bug.cgi?id=41564

Sinistar commented on 2019-04-21 18:00

Odd thing is, if you install it on a clean install, clang does not seg fault.

Lone_Wolf commented on 2019-04-16 01:13

I went back to the last llvm-svn version I had in cache (jan 14 2019) and found the clang in that package also segfaults.

There's some kind of problem with building clang + llvm together like it in llvm-svn and this package.

Going to bed now, will think tomorrow about changes