Package Details: llvm-ocaml-lw-git 9.0.0_r315265.6c9f6fd11b6-1

Git Clone URL: https://aur.archlinux.org/llvm-lw-git.git (read-only)
Package Base: llvm-lw-git
Description: OCaml bindings for LLVM
Upstream URL: https://llvm.org/
Licenses: custom:University of Illinois/NCSA Open Source License
Conflicts: llvm-ocaml
Provides: llvm-ocaml=9.0.0_r315265.6c9f6fd11b6-1, llvm-ocaml-git=9.0.0_r315265.6c9f6fd11b6-1
Submitter: Lone_Wolf
Maintainer: Lone_Wolf
Last Packager: Lone_Wolf
Votes: 1
Popularity: 0.406871
First Submitted: 2019-04-06 15:22
Last Updated: 2019-04-29 22:02

Pinned Comments

Lone_Wolf commented on 2019-05-17 22:15

This package is now obsolete, switch to llvm-minimal-git instead.

Latest Comments

1 2 3 Next › Last »

Lone_Wolf commented on 2019-05-17 22:15

This package is now obsolete, switch to llvm-minimal-git instead.

Lone_Wolf commented on 2019-04-30 10:05

I've done that about 11 hours ago.

And you are right, the lib32 does tend to lag behind. Building and testing these packages takes a lot of time, even on a threadripper 1920x with an nvme2 PCIe ssd that uses ccache.

QuartzDragon commented on 2019-04-30 02:01

Thanks! Best of both worlds. :)

Are you able to sync up the lib32-llvm-lw-git and lib32-llvm-libs-lw-git packages with this one? The lib32 packages often seem to fall behind in terms of syncing up.

QuartzDragon commented on 2019-04-29 14:53

It's the best compromise we can come to. :)

Lone_Wolf commented on 2019-04-29 14:50

It wasn't a caching issue, quartzdragon.

I uploaded a new version of llvm-git that also doesn't provide llvm anymore.

I thought there was no gcc--git, so no example how to do things. I checked and gcc-git does exist and provides a specific gcc version.

That's a solution I can live with, provide a specific version of llvm and co.& instead of generic.

Can you live with that ?

Lone_Wolf commented on 2019-04-29 13:22

as I tried to make clear there's very little reason to keep llvm / llvm trunk / llvm7 / llvm6 etc installed after building has finished. removing makedepends is a good practice and helps to keep a system healthy by removing unneeded stuff.


You have a package that has llvm as makedepend and llvm-libs as depend.

Packages build with a certain version of llvm need to have runtime libraries of that same version (there's some wiggle rooom, but not much).

If you build that package against llm-lw-git , you will need to edit the PKGBUILD to add llvm-libs-lw-git to depends. Should you neglect to do that, upon installing the package pacman won't be informed your package needs llvm-libs-lw-git . As soon as llvm-libs-lw-git is removed the package will fail.

Since you already need to adjust the PKGBUILD to make sure the correct runtime libraries will be installed, why not change the llvm makedep to llvm-lw-git also ?

QuartzDragon commented on 2019-04-29 13:16

Okay, I must have had a cached page or something, but I saw tons of packages depending on llvm-git due to the llvm provides.

I think my argument is a meaningful one, however.

For instance... what if you're using gcc-git, and some package demands gcc as a dependency? gcc-git must provide gcc, so that there's no conflict, because obviously, you want those packages to use gcc-git instead.

Same thing with clang ~ using clang-git, and a package demands clang? Obviously, you want it to use clang-git, therefore, to shut up the package from complaining, either you need to alter that package's PKGBUILD, or more simply, just make clang-git provide clang.

QuartzDragon commented on 2019-04-29 12:34

One argument is that what if you have llvm-lw-git installed, and because it doesn't act as a provider for llvm, some other package you're trying to build therefore tries pulling in stable llvm as a dependency when you may well desire to make it use llvm-git instead?

If someone wants to build a package with stable llvm, let them install that instead. For those of us that desire to make a package use llvm-git, satisfying that dependency is useful.

If you look at llvm-git AUR, count all of the packages that have an llvm make requirement, and maybe you'll start to see what I mean.

Lone_Wolf commented on 2019-04-29 12:04

robus, llvm-libs-lw-git doesn't provide everything llvm-libs does. Pacakges that expect llvm-libs may not work when only llvm-libs-lw-git is installed. You can have llvm-libs and llvm-libs-lw-git installed together though.

What problems are you getting ?


About llvm-lw-git providing llvm : Only 3 packages have a runtime dependency on llvm, all other programs have it as makedepend or checkdepend and don't need it at runtime.

  • lib32-llvm is makedepend for 2 pacakges
  • llvm-ocaml nothing has it as runtime dependency
  • shiboken2 is a makedepend for 3 other packages

The only reason I can think of to keep llvm installed permanently is developers that want to be able to run llvm/clang/ocaml from IDEs or CLI. I don't see why they'd want llvm trunk versions to pretend they're llvm stable though. Quartzdragon and others that think i'm wrong : please explain your reasoning

QuartzDragon commented on 2019-04-29 01:09

robus, what's broken?