Package Details: llvm-ocaml-git 18.0.0_r484887.953ae94149f0-1

Git Clone URL: https://aur.archlinux.org/llvm-git.git (read-only, click to copy)
Package Base: llvm-git
Description: OCaml bindings for LLVM
Upstream URL: https://llvm.org/
Keywords: clang git lld lldb llvm polly
Licenses: custom:Apache 2.0 with LLVM Exception
Conflicts: llvm-ocaml
Provides: llvm-ocaml
Submitter: yurikoles
Maintainer: rjahanbakhshi
Last Packager: rjahanbakhshi
Votes: 118
Popularity: 0.005241
First Submitted: 2018-12-05 13:56 (UTC)
Last Updated: 2024-04-17 08:17 (UTC)

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

  1. This package

    • It aims to provide a full llvm/clang compiler environment for development purposes.
    • Supports cross-compiling , bindings for external stuff (python, ocaml etc) , and some things not in extra-llvm.
    • intended to be used with archlinux core,extra & community repos
    • CONFLICTS with extra llvm/clang packages
    • Currently there's no repo with binary versions
  2. llvm-minimal-git

    • focuses on providing stuff needed for AUR mesa-git. Doesn't support cross-compiling or any bindings for external stuff like ocaml & python.
    • intended to be used with archlinux core,extra & community repos
    • compatible with extra llvm/clang packages
    • no repo with binary versions
  3. packages created & maintained by Lordheavy, an arch developer

    • intended to be used with archlinux testing repos
    • sometimes has problems on systems where testing repos are disabled
    • uses same package structure as llvm/clang in official repos
    • source
    • binary versions in LordHeavys unoffical repo

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.

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

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 .. 17 18 19 20 21 22 23 24 25 26 27 .. 70 Next › Last »

Lone_Wolf commented on 2019-04-28 13:16 (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.

lahwaacz commented on 2019-04-28 12:17 (UTC)

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 (UTC)

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 (UTC)

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 (UTC) (edited on 2019-04-27 13:11 (UTC) by Lone_Wolf)

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 (UTC)

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 (UTC)

Bug report for broken Clang:

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

Sinistar commented on 2019-04-21 18:00 (UTC)

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 (UTC)

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