<drakonis>
perhaps, but most of the sentiment towards it, is that it didnt need to be built into the nix code basre
<drakonis>
base
<simpson>
Sure. None of this was at all necessary.
<drakonis>
then there's the part where it tried to embrace the world in one go
<drakonis>
i think the first thing that should've been shipped was a better way to manage channels than what's currently available for nix
<drakonis>
trying to do lock files too seems like a huge crutch
<drakonis>
and given nix's ecosystem's fragmented nature, it would've been perhaps best to simply provide the tools for building something
<simpson>
Maybe. Or maybe channels were a mistake and should be removed entirely.
<drakonis>
channels as nix currently has are a huge huge mistake
<drakonis>
guix did channels in a vastly simpler way
<drakonis>
you declare your channels and they're accessible on the top level
<drakonis>
the modules provided by the channels are accessible and have to be brought into scope
<drakonis>
this is the thing i think nix as a dsl is running into a wall
<drakonis>
due to it being, for nearly all of its history, focused on nixpkgs, it never grew a reasonably clean abstraction for handling modules
<drakonis>
not modules in the nixpkgs sense that is
<drakonis>
but libraries
<drakonis>
it never had a need for that due to the megarepo containing the kitchensink
<drakonis>
now that flakes exists, the issue is becoming far more visible
<drakonis>
we're paying tech debt here
<drakonis>
probably not as well as we could
<drakonis>
but it is something
<drakonis>
i'll bring this topic to next week, as per requested on the other channels btw
<drakonis>
its a hot hot topic here.
<drakonis>
anyways, i'm very ranty right now
<sterni>
Ericson2314: any idea why `-lunwind` is only added to ldflags in lldClang if hostPlatform.isAndroid? seems like this is actually necessary to compile (trivial) C++ programs as well
drakonis has quit [Quit: WeeChat 3.1]
drakonis has joined #nixos-exotic
<Ericson2314>
sterni: that was a new thing from the android PR
<Ericson2314>
I just assumed this wasn't neaded elsewhere or someone would have already done that :)
<Ericson2314>
sterni: perhaps it should be tied to `-fexceptions` `-fno-execeptions `somehow?
<Ericson2314>
(I think that's what the flag is called)
<sterni>
Ericson2314: yeah I am thinking about adding that stuff to the useLLVM && !isWasm section
<Ericson2314>
sterni: did you you see my choose-the-linker one?
<sterni>
Ericson2314: yeah, I've been meaning to review it but haven't gotten to it yet
<sterni>
sounds like a good idea in any case
<sterni>
earlier today I was trying to get nix to build with useLLVM, but things go all kinds of wrong with boost and I haven't had the motivation to fix it
<sterni>
but we can compile stuff like c-ares, ncurses, abseil-cpp with useLLVM when adding the -lunwind flag which is promising
<Ericson2314>
sterni: that is with llvm 7?
<Ericson2314>
glad that's working
<Ericson2314>
I feel like for everthinng I make better I also break something! :/
<drakonis>
sometimes you gotta break things to fix others
<sterni>
Ericson2314: uh I tried with 11 which worked better
<sterni>
I'll need to investigate 7 again
<sterni>
actually I just need to figure out the issue with lldClang && useLLVM precisely and do a change PR for it
<sterni>
looks like new apple sdk and llvm 11 isn't going anywhere really? :(
<sterni>
Ericson2314: I'm getting the impression that making changes to LLVM is actually really hard without breaking stuff because there are so many moving parts, a lot of strange ways stuff interacts with each other and obscure things that isn't widely used like useLLVM
<Ericson2314>
sterni: yeah I am hoping to regularize thing because the combinatorial explosion right now is just too much
<Ericson2314>
we have to really straightjack everything into standardized interfaces
<Ericson2314>
so we can trust that the combinatorial explosion all works by conforming those interfaces
<sterni>
Ericson2314: seems like lld needs libunwind for mach-o related headers (but only the headers)
<sterni>
odd grouping in any case
<Ericson2314>
sterni: does is use those headers at build time, or do something like a resource dir?
<Ericson2314>
sterni: ok check out that PR againn
<Ericson2314>
I fixed conflicts and made the firefox lld thing much less ridiculous
<sterni>
it always amuses me reading bintools in nixpkgs because somewhere in stdenv there is this comment explaining that we use the >>neutral<< name bintools for stdenv.cc.bintools
<sterni>
whereas this is in actual fact not neutral at all
<sterni>
although maybe that was done before llvm bintools was around?
<Ericson2314>
sterni: yes that was done by me before llvm-bintools was around
<Ericson2314>
and does upstream llvm call it that?
<Ericson2314>
I didn't think so
<sterni>
it probably doesn't
<simpson>
What are they called on BSD? I'm used to the biased name `bsdutils`, which is probably not what they call their own utilities.
<Ericson2314>
simpson: i thought they used gnu binutils
<Ericson2314>
or maybe lld
<Ericson2314>
they have their own ld.so
<Ericson2314>
but that's provided by glibc in GNU land
<qyliss>
Ericson2314: FreeBSD and OpenBSD use LLVM, and NetBSD uses GCC and binutils
<sterni>
Ericson2314: so the linker change basically allows us to have useLLVM with different linkers than lld in theory
<sterni>
for the other stdenvs we only record which linker is in use basically
<sterni>
(since the top level bintools isn't used anywhere else)
<sterni>
so the idea is to have proper working useLLVM stdenvs for darwin, bsd in the future?
<sterni>
for cross at least?
<Ericson2314>
sterni: yeah, or even start removing some useLLVM because it's always true :)
<sterni>
huh where do we do that?
<sterni>
useLLVM only has relevancy for cross, no?
<Ericson2314>
sterni: well for starters I hope the new darwin stuff can be folded into that
<Ericson2314>
so basically we get back to clang with gcc libs vs clang with llvm libs
<sterni>
that sounds cool
<sterni>
we have like what? at least 4 different llvm stdenvs?
<sterni>
well libcxxStdenv and llvmPackages.stdenv doesn't really count because it depends on stdenv
<Ericson2314>
sterni: once we have the gcc libs always built separately
<Ericson2314>
(see my old libgcc derivation)
<Ericson2314>
then we can do something like this `linker` field for that