{`-`} has joined #nixos-rust
samueldr has joined #nixos-rust
<drakonis> hello world
arcnmx has joined #nixos-rust
simpson has joined #nixos-rust
<arcnmx> the matrix bridge is awful, is this even working?
<simpson> Yes. And also yes.
<qyliss> arcnmx: yes
<drakonis> rust crew represent?
<arcnmx> o, it just doesn't add people to the room until they talk I guess
<clever> something i'm also mildly interested in
<clever> rust + vc4
<pie_[bnc]> I'm trying to build grub modules in rust
<pie_[bnc]> (no reason)
lovesegfault has joined #nixos-rust
<clever> what would it take to port rust to a new arch?
cole-h has joined #nixos-rust
<lovesegfault> Wow, I barely joined and it's already cursed :)
<pie_[bnc]> lol
<pie_[bnc]> its lovesegfault for a reason
<pie_[bnc]> clever: probably porting core?
lovesegfault is now known as lovejobsecurity
<lovejobsecurity> yes
lovejobsecurity is now known as lovesegfault
<pie_[bnc]> the reddit post looks like a start
<clever> i'm guessing a llvm backend is the first thing you need?
<lovesegfault> clever: Yes
<clever> lovesegfault: https://github.com/christinaa/LLVM-VideoCore4 might that be enough?
<lovesegfault> This is why Rust AVR is sadly not a thing
<clever> lovesegfault: i have seen an avr llvm backend
evanjs has joined #nixos-rust
<lovesegfault> the AVR backend of LLVM was merged upstream but never left staging
<lovesegfault> and so the Rust fork with AVR support was never merged
<evanjs> Oooo wait was this always a thing?
* lovesegfault weeps in Atmel
<clever> lovesegfault: ive used it in nixpkgs, by just doing a package override
<evanjs> The channel, I mean
<clever> lovesegfault: and yes, it segfaults llvm, lol
<lovesegfault> :D
<clever> llvm = llvm.overrideAttrs (old: {
<clever> cmakeFlags = old.cmakeFlags ++ [ "-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=AVR" ];
<clever> thats all i needed, i believe
<lovesegfault> jesus
<clever> gotta love nix :P
<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
<arcnmx> Yeah, the mozilla overlay is only able to download prebuild binaries, so if your target isn't on https://forge.rust-lang.org/release/platform-support.html , you'll need to build from source.
<pie_[bnc]> s/nobody made/cargo does not provide/
<pie_[bnc]> arcnmx: yes its not on there
<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
* pie_[bnc] doesnt really know why its bad
<qyliss> pie_[bnc]: FODs are bad
<pie_[bnc]> "and how have i not heard of it yet"
* 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> (or invoke rustc with --sysroot= iirc)
<pie_[bnc]> this makes me further assume its indeed the right src dist https://github.com/mozilla/nixpkgs-mozilla/blob/master/rust-src-overlay.nix
<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
<pie_[bnc]> arcnmx: hows this https://bpaste.net/NYVA
<arcnmx> not including https://github.com/rust-lang/rust/blob/master/Cargo.lock is probably not great
<arcnmx> oh wait I'm blind
<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]> lol nevermind something broke
<pie_[bnc]> glue time anyway
<pie_[bnc]> idk but peeking at this suggests to me that i should probably be compiling with xbuild instead of with some nix/cargo stuff https://github.com/rust-osdev/cargo-xbuild/blob/master/src/sysroot.rs
<pie_[bnc]> the whole thing seems to culminate in building liballoc though? which i havent heard of yet
<pie_[bnc]> i thought compiler_builtins and whatever else, like core, etc were separate
<pie_[bnc]> `An intermediate subset of the standard library smaller than “all of std” but larger than “only core” can serve such environments.`
<pie_[bnc]> sounds like there should be a possibility of an even smaller `core` too
<arcnmx> mm the sysroot is split up into std, alloc, core, etc. std generally requires an OS, the rest don't.
<pie_[bnc]> but maybe if youre compiling core you might as well compile liballoc
<pie_[bnc]> and thats why it does this
<pie_[bnc]> thats just guessing on my part though
<arcnmx> you generally do want it, yes
<arcnmx> even if you're not using it in a specific project, it's typically included
<arcnmx> in a sysroot
<pie_[bnc]> an example generated toml https://bpaste.net/IZUA
<pie_[bnc]> arcnmx: i guess the question in my mind is if you ever dont want it, like if theres extra porting effort or smething *shrug*
<pie_[bnc]> probably irrelevant
<arcnmx> not really? it's pretty standalone and requires no porting efforts afair
<pie_[bnc]> btw i segfault
<arcnmx> from the perspective of building a sysroot
<arcnmx> from the perspective of an embedded or bare metal project, there may be reasons to not want it :p
<pie_[bnc]> and i think i was segfaulting or otherwise erroring bfore i switched to trying to declarativize stuff https://bpaste.net/OKPA
<pie_[bnc]> guess i could try a less exotic build target than i686-elf
<pie_[bnc]> could be anything though
<pie_[bnc]> yeah looks like its not target specific
<arcnmx> mm could be a number of things, dunno o:
evanjs has quit [Quit: ZNC 1.7.5 - https://znc.in]
<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]> so that should be fine then
<pie_[bnc]> $ cargo xbuild --target rust/i686-grub.json
<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
<cole-h> Deps cache just fine for me.
<pie_[bnc]> wat https://bpaste.net/SBVQ
<pie_[bnc]> you could patch out the check :/
<pie_[bnc]> nevermind the error changed <pie_[bnc]> wat https://bpaste.net/SBVQ
<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)" })',
<lovesegfault> /home/bemeurer/.cache/cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.22.0/src/platform_impl/linux/mod.rs:569:9
<lovesegfault> Aight, idk how to use naersk :P
<lovesegfault> cole-h: What'd you do to get alacritty to run?
<pie_[bnc]> arcnmx: progress, unsure how to deal with deps however https://bpaste.net/ZFJA
<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? :/
<cole-h> Tried `src = ./path/to/whatever;`?
<pie_[bnc]> cole-h: it works if i just remove the line and add a sha256
<pie_[bnc]> but im reminded i do need the path here lol
<pie_[bnc]> oh jeez this is going to be hacky
<pie_[bnc]> i have to capture the temporary toml from xbuild, pass it to the deps grabber
<pie_[bnc]> (i think(
<pie_[bnc]> or patch xbuild