| Git Clone URL: | https://aur.archlinux.org/llvm-git.git (read-only, click to copy) |
|---|---|
| Package Base: | llvm-git |
| Description: | runtime libraries for llvm-git |
| Upstream URL: | https://llvm.org/ |
| Keywords: | clang git lld lldb llvm polly |
| Licenses: | custom:Apache 2.0 with LLVM Exception |
| Conflicts: | llvm-libs |
| Provides: | aur-llvm-libs-git, llvm-libs |
| Submitter: | yurikoles |
| Maintainer: | rjahanbakhshi |
| Last Packager: | rjahanbakhshi |
| Votes: | 118 |
| Popularity: | 0.22 |
| First Submitted: | 2018-12-05 13:56 (UTC) |
| Last Updated: | 2024-04-17 08:17 (UTC) |
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.
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.
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.
Isn't an alternative is to simply create a wrapper in prepare which calls /usr/bin/ninja or do i need to set $MAKEFLAGS
Confirmed, but leaving that out leads to overburdening of systems and memory swapping due to ninja (badly chosen imo) defaults.
i think you should delete $MAKEFLAGS from the build process because if you don't have $MAKEFLAGS enabled it fails
Bug report for broken Clang:
Odd thing is, if you install it on a clean install, clang does not seg fault.
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
Pinned Comments
Lone_Wolf commented on 2021-08-16 11:26 (UTC)
When you have this package installed applications that are built against repo-llvm/clang WILL fail unless they are rebuild against this package.
This includes QTCreator, kdevelop , mesa, intel-compute-runtime, gnome-builder to name a few.
Lone_Wolf commented on 2020-08-22 12:18 (UTC) (edited on 2021-02-06 12:51 (UTC) by Lone_Wolf)
Archlinux currently has 3 llvm git implementations
This package
llvm-minimal-git
packages created & maintained by Lordheavy, an arch developer
Lone_Wolf commented on 2019-04-12 20:41 (UTC) (edited on 2019-12-16 22:45 (UTC) by Lone_Wolf)
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.
llvm-git
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.
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.