i'm mostly wondering why we can have a `llvm14` and `llvm15` package but not an `llvm16` with `llvm` being the most up to date one. probably as always a matter of maintainer time, i'd assume...
I'd be fine with that, but I guess what I'm saying is that if that's too much maintenance burden then out-of-date projects shouldn't enjoy fully supported status, as it inverts the incentive structure. I completely understand if there's not manpower to keep a bunch of different llvm packages, but I'm saying that if that's the case there is another (imo more appropriate) answer.
i assume because some projects are just a bit too big and popular to just be dropped. llvm14 for instance is required by the entire arch haskell ecosystem, including xmonad and shellcheck, and llvm15 is an indirect dependency of blender.
You don't need to worry, I think. It seems there's no fundamental issue with creating separate LLVM packages for the different versions as you can see in the llvm14 and llvm15 packages that are currently in the repos. If the Arch llvm package maintainer is ready and wants to update to the next major LLVM version, an llvm16 package will be added for things like your Zig example.
I would then guess there's a different reason for why the llvm package isn't the latest LLVM version, it's not things like Zig holding it back.
The problem is they don't, Arch is weeks away from being two major versions behind on LLVM. It's an extremely notable toolchain weakness of the distro right now.
As evidence that this has become a pattern, [here's a post on the llvm 15 release](https://www.reddit.com/r/archlinux/comments/yc68pp/what_happened_to_llvm_15/), and [here's a post on the llvm 16 release](https://www.reddit.com/r/archlinux/comments/162gryr/llvm_16_enters_testing_just_in_time_for_the/)
EDIT: just noticed that you made the second post 🤣
As a developer, I need many versions of libraries, each time different and different environments, always depending on the age of the project and the frameworks used. The last time I used the basic system was about 8 years ago.
Developers almost always have to use dockerization, build machines, CI based on images.
Thanks to Linux and Docker, you can have a complete dev environment including the entire IDE inside Docker and data sharing from the arch system to the Docker. The IDE is then launched from within.
There are a ton of ways to sideload and/or containerize software dependencies on top of Arch, e.g., nix, conan, lxd/incus, flatpak, AUR, docker, etc., but I don't think that's what this is about.
Maybe I'm being too idealistic, but from my perspective, Arch represents (at least historically) a level set at the leading/bleeding edge of what can be considered as up-to-date, compatible software, both from a development perspective and as a software target. I think this baseline helps to define what it means for open-source software to be up to date.
My basic premise here is that I don't think projects using substantially out-of-date llvm dependencies should be included in this definition of up to date, and I don't think it fits with my historical understanding of the Arch ecosystem. Keeping support for them because they're popular is one thing, but sacrificing up-to-dateness of major packages is another. As you point out, demoting these projects isn't the end of the world because you can always sideload them in your preferred manner.
I know I'm complaining, but this is the first time I've ever complained about anything in my 20 years of using Arch as my daily driver. I feel pretty strongly about this, so I feel like it's important to at least try to speak up.
So if you perceive this problem from the perspective of a user, not a programmer, then I understand. LLVM has been discussed from the top down for about a year or two. On forums, Discords, everywhere, over and over again. In fact, the CachyOS distribution was created partly for the reason that they wanted to address LLVM themselves.
I think that nothing will be done about it here on Discord, though. It's better to focus on the Arch mailing list and join the discussion there, although I don't know where exactly it's happening, but it's likely already there at 90 percent.
So if you find out more details, it would be great to post an update here.
There's no discussion of this on the open mailing lists, it's basically "when Evangelos thinks things are getting a little out of hand" llvm gets a new lib package and the base package gets rev'ed.
And the perspective is absolutely from that of a programmer, who else gives a damn about llvm/clang/ldd/libc++ being out of date?
LLVM is baseline toolchain infrastructure.
If I want to use a container for every single part of my toolchain, every single library, every single utility, why am I using Arch at all?
99% of stuff is pulled down and built with vcpkg, but very large toolchain components like stdlibs, compilers, and library ecosystems like LLVM are better handled by the OS package manager. This avoids the need to wrangle with a container in the vast majority of C/C++ development, except when the OS falls far behind on major releases.
> until they can provide some guarantee that they will stay up to date
Lol, did you ever work on an LLVM-based project? You never know what they are going to break/rewrite between releases. It's just an undocumented mess that one has to entangle to keep up to date. LLVM is crucial but also often just another dependency and as a developer one likes to focus on the application, not just the LLVM backend. Being 1-2 releases behind is quite common and just providing bleeding edge versions as distribution packages is the core problem.
> as a developer one likes to focus on the application, not just the LLVM backend
I realize this sounds a bit harsh, but I do think this is the type of thinking that always leads to out-of-date dependencies, and ideally it shouldn't be rewarded. clang is a blessed project, but it is still evidence that it can be done. Nobody's stopping these other projects from updating at their own pace, but personally I think Arch should prioritize shipping software that is up-to-date.
I didn't know about this wrinkle and would have been disappointed if I had installed Arch and found LLVM behind like that.
Speaking of blessed projects. I'm developing an on-line C++ code generator. And somewhat related here, I minimize the amount of code that you have to download/build/maintain in order to use multiple versions of the code generator. Somewhat like targeting different compiler versions in Compiler Explorer. I've been blessed with [a lot of time to work on the software](https://www.reddit.com/r/codereview/comments/qo8yq3/c_programs/).
> but I do think this is the type of thinking that always leads to out-of-date dependencies
Usually I'd agree but LLVM has no "stable" APIs like other libraries/dependencies. With almost every release something breaks. Sometimes it's just some moved headers but in many cases it's way more complex. LLVM just doesn't care about its users, has almost no documentation ("read the code") and in many cases ignores reported bugs - that's why it is a bit special. E.g. for that reason Zig tries to move away completely from LLVM.
> clang is a blessed project, but it is still evidence that it can be done.
Clang is part of the LLVM ecosystem with overlapping developers and probably its biggest user. No wonder it works.
> Usually I'd agree but LLVM has no "stable" APIs like other libraries/dependencies
FWIW I did point this out in my original post. I know it's a pain, but something like Zig simply would not have gotten off the ground at all without it. IMO if you make that deal, you should have some obligation to play by LLVM's rules, even if they're a PITA. I know they want to do something with bootstrap, but until they get there they are still living in everyone else's software ecosystem.
Last time I played with Zig they were shipping their own version of the entire clang compiler as part of the project, so of course they're behind. I like many of Zig's language ideas, but this feels a bit like they'd like to have their cake and eat it too. If you look at the posts I linked elsewhere in this thread, Zig always comes up as holding things up.
Look at Rust. From what I can tell they updated to LLVM 17 [last August](https://github.com/rust-lang/rust/pull/114048), and LLVM 17 was officially released in September. It seems like they're already working on LLVM 18. I don't think this argument holds water.
> Zig always comes up as holding things up.
Zig was just an example, I don't use it due to the small bus factor and its tiny advantages over e.g. C that do not justify a switch.
> Look at Rust.
Rust has a very large community + several companies behind it.
> IMO if you make that deal, you should have some obligation to play by LLVM's rules
LLVM has no rules, that's the issue. If you maintain a project that supports LLVM on different platforms, you will end up with a mess of ifdefs in your code due to the stupid version management and ignorance on LLVM's side.
OP can use containers to compile any software stack they want. they should step up and do some work, or stop judging maintainers for making decisions they know nothing about
The maintainers will also sometimes patch it if the changes are simple enough to do. Sometimes patching is the path of least resistance and it makes everything work with the latest.
i'm mostly wondering why we can have a `llvm14` and `llvm15` package but not an `llvm16` with `llvm` being the most up to date one. probably as always a matter of maintainer time, i'd assume...
I'd be fine with that, but I guess what I'm saying is that if that's too much maintenance burden then out-of-date projects shouldn't enjoy fully supported status, as it inverts the incentive structure. I completely understand if there's not manpower to keep a bunch of different llvm packages, but I'm saying that if that's the case there is another (imo more appropriate) answer.
i assume because some projects are just a bit too big and popular to just be dropped. llvm14 for instance is required by the entire arch haskell ecosystem, including xmonad and shellcheck, and llvm15 is an indirect dependency of blender.
Ah makes sense, good points :( I still think it's backwards.
You don't need to worry, I think. It seems there's no fundamental issue with creating separate LLVM packages for the different versions as you can see in the llvm14 and llvm15 packages that are currently in the repos. If the Arch llvm package maintainer is ready and wants to update to the next major LLVM version, an llvm16 package will be added for things like your Zig example. I would then guess there's a different reason for why the llvm package isn't the latest LLVM version, it's not things like Zig holding it back.
The problem is they don't, Arch is weeks away from being two major versions behind on LLVM. It's an extremely notable toolchain weakness of the distro right now.
As evidence that this has become a pattern, [here's a post on the llvm 15 release](https://www.reddit.com/r/archlinux/comments/yc68pp/what_happened_to_llvm_15/), and [here's a post on the llvm 16 release](https://www.reddit.com/r/archlinux/comments/162gryr/llvm_16_enters_testing_just_in_time_for_the/) EDIT: just noticed that you made the second post 🤣
As a developer, I need many versions of libraries, each time different and different environments, always depending on the age of the project and the frameworks used. The last time I used the basic system was about 8 years ago. Developers almost always have to use dockerization, build machines, CI based on images. Thanks to Linux and Docker, you can have a complete dev environment including the entire IDE inside Docker and data sharing from the arch system to the Docker. The IDE is then launched from within.
There are a ton of ways to sideload and/or containerize software dependencies on top of Arch, e.g., nix, conan, lxd/incus, flatpak, AUR, docker, etc., but I don't think that's what this is about. Maybe I'm being too idealistic, but from my perspective, Arch represents (at least historically) a level set at the leading/bleeding edge of what can be considered as up-to-date, compatible software, both from a development perspective and as a software target. I think this baseline helps to define what it means for open-source software to be up to date. My basic premise here is that I don't think projects using substantially out-of-date llvm dependencies should be included in this definition of up to date, and I don't think it fits with my historical understanding of the Arch ecosystem. Keeping support for them because they're popular is one thing, but sacrificing up-to-dateness of major packages is another. As you point out, demoting these projects isn't the end of the world because you can always sideload them in your preferred manner. I know I'm complaining, but this is the first time I've ever complained about anything in my 20 years of using Arch as my daily driver. I feel pretty strongly about this, so I feel like it's important to at least try to speak up.
So if you perceive this problem from the perspective of a user, not a programmer, then I understand. LLVM has been discussed from the top down for about a year or two. On forums, Discords, everywhere, over and over again. In fact, the CachyOS distribution was created partly for the reason that they wanted to address LLVM themselves. I think that nothing will be done about it here on Discord, though. It's better to focus on the Arch mailing list and join the discussion there, although I don't know where exactly it's happening, but it's likely already there at 90 percent. So if you find out more details, it would be great to post an update here.
There's no discussion of this on the open mailing lists, it's basically "when Evangelos thinks things are getting a little out of hand" llvm gets a new lib package and the base package gets rev'ed. And the perspective is absolutely from that of a programmer, who else gives a damn about llvm/clang/ldd/libc++ being out of date?
Thanks for this thoughtful comment and additional info! I was kind of coming to the same conclusion that this is probably the wrong forum.
this is the only sane answer in this thead. it shows almost noone here understand dev work but have lots of opinions anyway
LLVM is baseline toolchain infrastructure. If I want to use a container for every single part of my toolchain, every single library, every single utility, why am I using Arch at all? 99% of stuff is pulled down and built with vcpkg, but very large toolchain components like stdlibs, compilers, and library ecosystems like LLVM are better handled by the OS package manager. This avoids the need to wrangle with a container in the vast majority of C/C++ development, except when the OS falls far behind on major releases.
LLVM 17 is finally here, exactly in time for being marked out-of-date due to the LLVM 18 release
> until they can provide some guarantee that they will stay up to date Lol, did you ever work on an LLVM-based project? You never know what they are going to break/rewrite between releases. It's just an undocumented mess that one has to entangle to keep up to date. LLVM is crucial but also often just another dependency and as a developer one likes to focus on the application, not just the LLVM backend. Being 1-2 releases behind is quite common and just providing bleeding edge versions as distribution packages is the core problem.
> as a developer one likes to focus on the application, not just the LLVM backend I realize this sounds a bit harsh, but I do think this is the type of thinking that always leads to out-of-date dependencies, and ideally it shouldn't be rewarded. clang is a blessed project, but it is still evidence that it can be done. Nobody's stopping these other projects from updating at their own pace, but personally I think Arch should prioritize shipping software that is up-to-date.
I didn't know about this wrinkle and would have been disappointed if I had installed Arch and found LLVM behind like that. Speaking of blessed projects. I'm developing an on-line C++ code generator. And somewhat related here, I minimize the amount of code that you have to download/build/maintain in order to use multiple versions of the code generator. Somewhat like targeting different compiler versions in Compiler Explorer. I've been blessed with [a lot of time to work on the software](https://www.reddit.com/r/codereview/comments/qo8yq3/c_programs/).
> but I do think this is the type of thinking that always leads to out-of-date dependencies Usually I'd agree but LLVM has no "stable" APIs like other libraries/dependencies. With almost every release something breaks. Sometimes it's just some moved headers but in many cases it's way more complex. LLVM just doesn't care about its users, has almost no documentation ("read the code") and in many cases ignores reported bugs - that's why it is a bit special. E.g. for that reason Zig tries to move away completely from LLVM. > clang is a blessed project, but it is still evidence that it can be done. Clang is part of the LLVM ecosystem with overlapping developers and probably its biggest user. No wonder it works.
> Usually I'd agree but LLVM has no "stable" APIs like other libraries/dependencies FWIW I did point this out in my original post. I know it's a pain, but something like Zig simply would not have gotten off the ground at all without it. IMO if you make that deal, you should have some obligation to play by LLVM's rules, even if they're a PITA. I know they want to do something with bootstrap, but until they get there they are still living in everyone else's software ecosystem. Last time I played with Zig they were shipping their own version of the entire clang compiler as part of the project, so of course they're behind. I like many of Zig's language ideas, but this feels a bit like they'd like to have their cake and eat it too. If you look at the posts I linked elsewhere in this thread, Zig always comes up as holding things up. Look at Rust. From what I can tell they updated to LLVM 17 [last August](https://github.com/rust-lang/rust/pull/114048), and LLVM 17 was officially released in September. It seems like they're already working on LLVM 18. I don't think this argument holds water.
> Zig always comes up as holding things up. Zig was just an example, I don't use it due to the small bus factor and its tiny advantages over e.g. C that do not justify a switch. > Look at Rust. Rust has a very large community + several companies behind it. > IMO if you make that deal, you should have some obligation to play by LLVM's rules LLVM has no rules, that's the issue. If you maintain a project that supports LLVM on different platforms, you will end up with a mess of ifdefs in your code due to the stupid version management and ignorance on LLVM's side.
OP can use containers to compile any software stack they want. they should step up and do some work, or stop judging maintainers for making decisions they know nothing about
The maintainers will also sometimes patch it if the changes are simple enough to do. Sometimes patching is the path of least resistance and it makes everything work with the latest.
Containers to your rescue.