<clever>
lovesegfault: given that the vc4 repo has its own readme, it looks like an out-of-tree backend to llvm?, you got any clue how its built and tied into llvm?
<lovesegfault>
clever: (brb, brunch)
ekleog has joined #nixos-rust
<ekleog>
ohai
<cole-h>
o//save
<cole-h>
oops
<cole-h>
o/
<drakonis>
oho
Ericson2314 has joined #nixos-rust
<drakonis>
is this the cool kids table?
<pie_[bnc]>
obviouslty
<pie_[bnc]>
its rust
<pie_[bnc]>
spread the coolness
<pie_[bnc]>
its the cool kids table not because cool kids get to sit here but because sitting here *makes* you cool
<pie_[bnc]>
arcnmx: ok so for the mozilla overlay targets, is that *what my system is currently running*, *what i want to target* or both?
<pie_[bnc]>
if its the host system triple, thats fine i guess, because i need it to run, so the question is how do i make the target triple differ from the host triple
<pie_[bnc]>
ive been trying to coerce the mozilla infra, but i just realized if i have to rebuild rust, its not going to work no matter how much i try to coerce it into doing <????> when its just downloading binaries
<arcnmx>
so the mozilla overlay operates I believe... there's an option like additionalTargets or something you can set, and the rustc it downloads will run on the build system, while also being able to compile for / target the specified triples.
<arcnmx>
I do have my own overlay that determines this based on stdenv and does some extra fanciness, but there are parts of it that are a mess, so I probably shouldn't recommend it.
<pie_[bnc]>
ok ill try to look, but the whole premise is that probably nobody made binaries for the targets i want
<pie_[bnc]>
so unless rust's llvm can target everything (which is what id expect in this day and age, idk why youd have to recompile for different targets) id have to recompile
<pie_[bnc]>
does that mean i need to throw out the mozilla infra completely?
aleph- has joined #nixos-rust
<arcnmx>
while rustc can target anything (that it supports), and you can use a single binary to cross-compile for anything really, it requires libstd to be compiled for the target
<pie_[bnc]>
arcnmx: ok that makes it sound like i dont need to throw out the mozilla infra, i just need to build and point to a libstd
<drakonis>
channel not registered btw
<drakonis>
someone oughta register this
<arcnmx>
which needs to be packaged up for the compiler
<pie_[bnc]>
drakonis: i dont care to :D if anyone is up for it please do
<pie_[bnc]>
(arcnmx: at which point does it even matter what triples i set or can i just pass an empty target list ?)
<arcnmx>
it defaults to empty, and always including std for the build platform (otherwise build scripts couldn't build/run)
<arcnmx>
iirc
<pie_[bnc]>
ok i guess that makes sense
<drakonis>
well, only andi can
<drakonis>
gotta be chanop
<pie_[bnc]>
aha
<qyliss>
IIRC I had a patch to make the mozilla overlay build from source at some point
<qyliss>
Or somethin like that
<qyliss>
But that was a very long time ao
<arcnmx>
basically xargo's purpose is to automate the building libstd for an arbitrary platform, though some nix infra should be able to serve that purpose better
<pie_[bnc]>
qyliss: that would be appreciated, modulo the amount i stumble around with everything...
<pie_[bnc]>
arcnmx: so then that leaves the one question, you think its viable for me to stick to the mozilla infra and add some stuff for pointing to the right std? and do you have any idea how i'd go about that?
<pie_[bnc]>
arcnmx: i wish theyd manages to integrate xargo already but i already complained about that:P
<arcnmx>
main thing to note is that if you're using mozilla overlay, you'll need to grab the same src that built the compiler to build std for, and I'm not sure if the included src package for rls is sufficient
<pie_[bnc]>
arcnmx: ok se we're back at a) wrap xargo || b) write own wrapper infra
<qyliss>
pie_[bnc]: just had a look but can't find it :(
<pie_[bnc]>
qyliss: >w<
<pie_[bnc]>
doesnt sound too bad...theres a rust-src package thingy that hopefully works... <arcnmx> main thing to note is that if you're using mozilla overlay, you'll need to grab the same src that built the compiler to build std for, and I'm not sure if the included src package for rls is sufficient
<arcnmx>
the infra you use doesn't matter all that much? I might start with nixpkgs' and stable rust, and get that working
<arcnmx>
swapping out one rustc for another isn't a big deal, and that's all the mozilla overlay is for really
<andi->
go nuts, whatever yhou wnated to do
<drakonis>
haha
<pie_[bnc]>
someone please do the right thing :p
<arcnmx>
the main advantage of the overlay is to get nightly releases without needing to compile rustc from source yourself, but the process will be about the same regardless of whether you use stable, beta, or any random nightly
<pie_[bnc]>
arcnmx: yeah sure but it at least gives me some frame to think in
<pie_[bnc]>
aha
<pie_[bnc]>
well in theory we *arent* recompiling rust, just std
<cole-h>
Maybe the bot shouldn't have op, just in case... :P
* andi-
shrugs
<andi->
I'll go watch some Netflix.. Technology is terrible
* pie_[bnc]
pats andi-
<cole-h>
>using technology to escape technology
<cole-h>
:(
<andi->
Yeah, I saw that irony ;)
<pie_[bnc]>
cole-h: dont think about it
<pie_[bnc]>
so just checking, theres no such thing as rustPackages right?
<pie_[bnc]>
darned nix sha256-s :P
andi- changed the topic of #nixos-rust to: buildRustPackage is wrong.
<pie_[bnc]>
lol
<pie_[bnc]>
andi-: i dont suppose you have an issue to link there too
* arcnmx
needs to move to buildRustCrate but prior experience with it was scary
<qyliss>
when their output isn't really fixed
<pie_[bnc]>
qyliss: ah
<cole-h>
btw there is a `rustPackages`, but it appears to only be rustc and related stuff
<pie_[bnc]>
cole-h: yeah thats what i mean
<cole-h>
Not a `rustPackages.alacritty` kinda thing, but a `rustPackages.rls` kinda thing
<pie_[bnc]>
cole-h: an actual rustpackages
<pie_[bnc]>
i explained that terribly but you get it
* cole-h
doesn't get it
<pie_[bnc]>
oh cargo xbuild is a crate
<cole-h>
%%;
<cole-h>
^^;
<pie_[bnc]>
i wanted this <cole-h> Not a `rustPackages.alacritty` kinda thing, but a `rustPackages.rls` kinda thing
<cole-h>
got it
<cole-h>
Yeah, doesn't exist at the moment :)
<pie_[bnc]>
"Cargo-xbuild is a wrapper for cargo build, which cross compiles the sysroot crates core, compiler_builtins, and alloc for custom targets. It is a simplified fork of xargo, which is in maintainance mode." hm
<pie_[bnc]>
so....do i just buildrustpackage with that and thats it?
<pie_[bnc]>
how does this integrate with cargo
<pie_[bnc]>
(in nix)
<arcnmx>
the point of nix is that it removes the need for tools like that :p
<pie_[bnc]>
i just want my thing to build at all in the first plce xD
<pie_[bnc]>
(arguably i should be doing this imperativelt then, but i ran into trouble so declarative might be easier to mess with)
* pie_[bnc]
looks at crate2nix
<cole-h>
Should Rust things be transitioned to use `buildRustCrate`, then?
<arcnmx>
mm dunno, building std shouldn't be all that hard, but it's something I don't really know where to point to as a starting point
<pie_[bnc]>
well, now I know "sysroot" is a thing at least, and maybe the xbuild source isnt that complicated
<pie_[bnc]>
how bad could it be xD
<pie_[bnc]>
presumably you just need to cross compile the core crates and set an env var :P
<arcnmx>
it may be as easy as src = rustcSrc; buildCommand = "cargo build --target x -p std && install" or may be more annoying :p
<pie_[bnc]>
right x)
<arcnmx>
mm the sysroot is the directory that contains libstd (and its related deps)
<arcnmx>
something like $out/lib/rust/$target or something, then needs to be symlinked alongside rustc
<arcnmx>
the thing is the rust src tarballs distributed that way iirc just for deploying src for rls and are stripped of useful files (like Cargo.toml) which are kinda important for building it
<arcnmx>
but I may be remembering incorrectly
<pie_[bnc]>
youre probably not remembering incorrectly
<pie_[bnc]>
idk what rls is but a comment says its for intellij and stuff
<pie_[bnc]>
we will see
<qyliss>
It's the Language Server Protocol implementation
<arcnmx>
might work? it's missing things but not sure if they're essential for building or not - if tools like xargo/xbuild use it, then should be workable
<pie_[bnc]>
i dont know if they do
<pie_[bnc]>
but yeah now that you mention it the lock file sounds like it should be sufficient perhaps?
<pie_[bnc]>
sure you cant rebuild it (citation needed)
<pie_[bnc]>
i mean cant rebuild the lock file
<pie_[bnc]>
but luckily we probably dont need that
<pie_[bnc]>
i should have written a todo list heh, lots of stuff discussed, kind of lost track
* pie_[bnc]
continues with systroot
<pie_[bnc]>
wow big scary file :P @ target.nix
<pie_[bnc]>
arcnmx: so where do you actually compile the sysroot stuff
<arcnmx>
I don't, libstd/etc binaries are downloaded.
<arcnmx>
Like I said, I've been meaning to, but
<pie_[bnc]>
ah uhh right
<pie_[bnc]>
well xbuild seems to be mgically working, modulo everything is broken, so time to start figuring out how to glue stuff together
<pie_[bnc]>
xbuiild says If you want to use a local Rust source instead of rust-src rustup component, you can set the XARGO_RUST_SRC environment variable.
<pie_[bnc]>
I'd feel cleaner if i could build it in a bare env but sure whatever
<pie_[bnc]>
thread 'main' panicked at 'cargo metadata invocation failed: CargoMetadata { stderr: "error: could not find `Cargo.toml` in `/bakery2/oven1/personal/projects/modgrubrust/clean` or any parent directory\n" }', src/lib.rs:165:20
<lovesegfault>
What do y'all use other than crate2nix?
<cole-h>
naersk
<cole-h>
That's what I use to run alacritty and zoxide from source
<lovesegfault>
hmm
<lovesegfault>
Are you kidding me
<lovesegfault>
naersk only works with unstable Rust
* lovesegfault
sighs
<cole-h>
Wait what?
<cole-h>
How do you mean?
<lovesegfault>
Naersk relies on unstable cargo features
<cole-h>
Does it rely on those, though? What if you set `cargoOptions = "";`?
<lovesegfault>
then cargoBuildOptions doesn't work
<lovesegfault>
b/c --out-dir is unstable
<lovesegfault>
caching on naersk is also nonexistent apparently
<pie_[bnc]>
smh why do i need an entire dummy package to build sysroot
<lovesegfault>
thread 'main' panicked at 'Failed to initialize any backend! Wayland status: NoWaylandLib X11 status: LibraryOpenError(OpenError { kind: Library, detail: "opening library failed (libXcursor.so.1: cannot open shared object file: No such file or directory); opening library failed (libXcursor.so: cannot open shared object file: No such file or directory)" })',
<pie_[bnc]>
i could crate2nix it on the inside usinge the cargo.lock (maybe?) but id still have to fetch the deps
<arcnmx>
mm o:
<pie_[bnc]>
wellll i guess if i can generate fetch expressions i can IFD it
<pie_[bnc]>
but is there anything nicer?
<lovesegfault>
You can do IFD c2n
<pie_[bnc]>
lovesegfault: is a cargo.lock sufficient
<arcnmx>
dunno, there's buildRustPackage and buildRustCrate, both require the lock file, and what you use to generate for the latter will presumably require IFD regardless
<pie_[bnc]>
could fetch the whole alloc lib gir repo lol
<pie_[bnc]>
git
<pie_[bnc]>
(i ...think it was one repo?)
<pie_[bnc]>
ok lets try cn2
<pie_[bnc]>
c2n
<pie_[bnc]>
so I need to c2n the lib, then I need to expose some kind of directory of dependendencies
<pie_[bnc]>
can I take some subset of rust-src?
<pie_[bnc]>
also isnt there some way to make crate2nix not default to ./. being the source? :/