00:34 karolherbst: ohhh, why didn't I find std::sync::Once earler...
03:22 airlied: quiet #dri-devel $a:maidu123
03:40 kode54: I don't think that worked
03:41 kode54: persistent whackadoodle hasn't spoken up here yet, though
03:44 airlied: someone did it earlier in here I hadn't noticed
03:59 kode54: oh
03:59 kode54: I made the mistake of commenting about it and they started PMing me
03:59 kode54: apparently they think there are multiple mickey mouses in the world
04:00 kode54: because they want to "put [me] down like a mickey mouse"
04:00 kode54: hope I'm not on his persistent shitlist now, I don't really want to have to constantly add things to my ignore list
04:12 airlied: he's moved onto me now :-P
04:41 anholt: karolherbst: all my rust-code-in-mesa work was the ci-rust branch I pointed you at earlier. I didn't do anything with using external crates, since meson and cargo didn't seem like they get along much.
04:42 anholt: but if you're just looking for bindgen, seems like you could rely on people having cargo installed it and use it to do a custom_target in meson
04:46 orbea:shudders at the above
04:47 dcbaker[m]: I think airlied said relying on cargo would be a tough sell to distro people.
04:49 orbea: when you make a project rely on crates, this is what happens...just look at the sources list and please, no... https://slackbuilds.org/slackbuilds/14.2/system/alacritty/alacritty.info
04:50 airlied: like if bindgen was already packaged for distros and is just an external app dependency then it might be sane to use
04:51 airlied: but anything that involves recursive fetching of deps from a central language erpo is just not good for a system package
04:54 anholt: airlied: your distro packages firefox, yeah? you've probably already sorted that part out
04:54 anholt: (for chromeos, we run an internal crates repo as the thing fetched from for our ebuilds)
04:54 anholt: debian packages up the individual crates, not sure how they store the soruce
04:55 orbea: firefox's terrible build system is not an example of someting to aspire to
04:55 airlied: anholt: firefox isn't a system package like mesa though
04:56 anholt: airlied: the context was "what happens to mesa packages when we depend on crates" and i think the answer is "the same thing for the other packages in your distro that depend on crates, you've already solved this problem"
04:56 anholt: (ff probably actually isn't a good example, because I believe they vendor their crates in tree)
04:56 airlied: anholt: it's not really solved then
04:57 airlied: we appear to bundle at least cbindgen in firefox packages
04:57 orbea: yea, there are various poor hacks to work around the issue, no good solutions
04:57 anholt: https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/ <-- looks like fedora has pretty reasonable crates packaging.
05:00 anholt:just packaged probably 20 crates for chromeos last week because their basic build deps were super out of date. it was tedious, like any distro work, but really easy.
05:01 airlied: I don't think we should just go picing up misc crate deps for the lolz
05:01 anholt: sure!
05:01 anholt: not my argument
05:01 airlied: and I'd rahter we steered away from cargo completely if not required
05:02 airlied: I suppose whether it's required if up to when we land the first piece of rust code
05:07 orbea: if mesa depended on rust that would make rust a much harder dependency on distros....that could be painful in a lot of ways...
05:07 anholt: do you have a current distro that doesn't do rust?
05:08 anholt: like, even debian's obscure arches have rust.
05:08 orbea: im thinking about bootstrapping and minimal installs
05:08 orbea: rust is a pretty big and difficult to compile dependency
05:08 anholt: If you're struggling with building rust yourself, I would recommend using a distro.
05:09 orbea: ....that is not an argument
05:09 orbea: and its entirely irrelevant to rust being a large and unwieldly dependency
05:11 HdkR: Sounds like we need a rust-interpreter for those people that don't want to compile LLVM :P
05:11 orbea: llvm is easier to compile than rust :)
05:12 orbea: imagine the fun bisecting what rust commit broke mesa!
05:12 dcbaker[m]: Rustc is self hosting right?
05:12 anholt: dcbaker[m]: yes
05:13 orbea: iirc the madness with downloading stuff doesn't happen until cargo
05:17 dcbaker[m]: I would sure hope rustc doesn't need cargo to build. That would make bootstraping all but impossible
05:17 soreau: what is the benefit of using rust in mesa?
05:18 airlied: not using C++ :-P
05:18 anholt: soreau: the basic elevator pitch of rust.
05:18 soreau: anholt: I'm unfamiliar
05:18 anholt: soreau: fast, reliable, productive.
05:18 soreau: but the things being discussed seem to be the opposite :P
05:19 orbea: fwiw firefox never worked worse for me since it was rewritten in rust
05:19 anholt: notably, it's very hard to write rust code that crashes. Even the places that panic (kind of like abort), you have to explicitly write the code that triggers that.
05:19 HdkR: airlied: Let's just jump directly to C++20 and really push things to the limit
05:20 airlied: need to start a SYCL for rust project :-P
05:20 anholt: and on the other hand, it's very easy to write code that can do cool stuff that *can't* crash. the multithreaded deqp runner I just wrote was easy to write as a novice to the language, and I didn't have to worry about thread safety because the compiler made sure I couldn't screw it up (and people have made nice tools so it's trivial, too)
05:20 airlied: ah someone has :-p
05:21 airlied: or someone has at least started a repo :-P with no6thing it
05:37 orbea: HdkR: on Slackware the rust package is 670 MB, llvm is 317 :)
05:39 HdkR: That's chonky
08:59 MrCooper: orbea: it seems just a matter of time until Rust is considered as fundamental for a distro as C(++)
09:17 DPA: I'm not a fan of that. As it is right now, it's a giant SPOF. There is no complete & up to date alternative implementation of rust,
09:17 DPA: and there is no authoritative standard. Everything is bound to live, follows and die with that one implementation.
09:18 MrCooper: I'm sure there were similar complaints when C was introduced :)
09:19 Venemo: we can whine about rust all day long, but it exists and there're people who want to use it, so... why not?
09:21 simplycorbett: Hi all
09:21 Venemo: hi
09:22 simplycorbett: How would I go about compiling this in with the current mesa? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6429/
09:22 gitbot: Mesa issue (Merge request) 6429 in mesa "WIP: GLX Delay (accelerated GLX for Xwayland with the NVIDIA driver)" [Glvnd, Glx, Opened]
09:25 simplycorbett: xwayland is the only thing holding me back from a full transition over to wayland.
09:30 MrCooper: simplycorbett: per the "What's bad" section, it's currently a proof of concept with many caveats, not usable in practice yet
09:30 simplycorbett: Yes, that's fine with me. I just want to see how it runs
09:36 simplycorbett: I'm just not sure how to build a merge request. Do I just "check out branch"/download it and then compile?
09:38 Venemo: simplycorbett: you can clone the repo and check out the branch, then build. if this is your first attempt at something like this, I would strongly recommend against it. that branch is basically a proof of concept, not something you should be using
09:42 simplycorbett: So what is the current status of xwayland on eglstreams?
09:44 Venemo: as far as I know, pretty much what is written in the description of that MR
09:45 simplycorbett: If I can run my games fullscreen that's really all I need xwayland to do.
11:10 MrCooper: tjaalton: are there any non-Hurd architectures for which Debian builds Mesa with LLVM disabled?
11:22 karolherbst: dcbaker[m]: yeah, but distro do ship bindgen, so I don't think it's a huge problem
11:22 karolherbst: at least it seems to be used common enough so distros would be comfortable with this
11:44 tjaalton: MrCooper: no release architectures
11:44 MrCooper: that wasn't my question though :)
11:45 tjaalton: alpha hppa ia64 m68k riscv64 sh4 x32
11:46 MrCooper: thanks
13:19 karolherbst: pipe_loader bindings also working \o/
14:35 orbea: MrCooper: i have a friend who told me about a device he has that requires kernel 2.31.821 which he has been backporting fixes for a while now. Mesa git works on this, rust doesn't :)
14:44 vsyrjala: rust doesn't even have a distcc :(
14:44 karolherbst: vsyrjala: that would be quite painful to implement anyway
14:45 karolherbst: you don't call rustc on files
14:45 karolherbst: but you call it on an entry point and the *.rs files tell rustc what to pull in additionally
14:47 vsyrjala: doesn't sound all that different to cpp
14:48 karolherbst: vsyrjala: distcc does call cpp locally, no?
14:48 vsyrjala: yes, in non-pump mode
14:48 karolherbst: yeah, so you send something over which doesn't have external deps
14:48 karolherbst: how'd you do it with rust files?
14:48 karolherbst: you need some intermediate result
14:49 karolherbst: although, maybe you could send the MIR over
14:49 karolherbst: rustc --emit mir or whatever is the first thing.. maybe llvm-bc/llvm-ir?
14:49 karolherbst: dunno
14:50 vsyrjala: in the menatime i blacklisted all rust stuff on my slow machines
15:02 pendingchaos: jekstrand: ok if I add my R-b to the reviewed commits in !6991 and merge them and "spirv: Update headers and metadata from latest Khronos commit" as part of !7234?
15:36 jekstrand: pendingchaos: Go for it
15:38 jekstrand: pendingchaos: Do you want me to quick deal with your comments first?
15:38 pendingchaos: jekstrand: sure
15:39 jekstrand: Rebasing now
15:39 karolherbst: jekstrand: so.. in regards to nir and rust. I think as long as we keep passes and such in C code, there is no problem using the nir API. Even inline functions are fine. If we want to write passes in rust, we might get away by having functions for all data manipuation.
15:40 karolherbst: so as long as all list stuff is wrapped by C functions we should be able to do everything
15:40 jekstrand: karolherbst: I suspect for the purposes of clover, we should probably just keep the one or two passes it needs in C
15:40 karolherbst: yeah, that's probably good enough, just a bit annoying :D
15:40 karolherbst: but yeah
15:41 jekstrand: Though if you want a pass which adds stuff to CL objects and then rewrites, yeah, that's tricky.
15:41 karolherbst: didn't arrive at the compiler yet, but until now everything just works
15:41 karolherbst: jekstrand: we can always add inline functions inside the bindgen header
15:41 karolherbst: and tell bindgen to provide rust wrappers
15:42 karolherbst: the structs are directly exposed to rust
15:43 karolherbst: so I think the only annoying bits are iterators, but we could have a callback styled wrapper API for that
15:43 karolherbst: or something
15:43 karolherbst: besides that? I don't think we need anything else
15:43 karolherbst: we can't use macros, that's the only problem
15:44 jekstrand: karolherbst: The iterators call functions too, for the most part.
15:44 karolherbst: well.. we can also just the link lists and do the manipulation through unsafe { } and .as_mut_ptr() and stuff
15:44 jekstrand: karolherbst: We could make iterators for rust, they just wouldn't be safe.
15:44 karolherbst: yeah...
15:44 karolherbst: but
15:44 karolherbst: all bindgen funcs are unsafe anyway
15:44 karolherbst: so...
15:45 karolherbst: we just need to write nice rust wrappers around the unsafe stuff regardless
15:45 karolherbst: or don'y
15:45 karolherbst: *don't
15:45 karolherbst: really doesn't matter
15:45 karolherbst: you can use unsafe everywhere
15:45 karolherbst: even inside safe functions
15:47 karolherbst: the biggest issues I am facing are simply some meson bugs (probably?) and not being able to use external crates :/
15:48 jekstrand: pendingchaos: Did you or someone else ACK the header update?
15:49 pendingchaos: I don't think so
15:49 jekstrand: I'm pulling the very latest now
15:52 jekstrand: pendingchaos: MR updated
15:52 jekstrand: pendingchaos: If you want to give me an ACK for the SPIR-V bits, I'll break off an MR and get the first half merged.
15:55 pendingchaos: it looks fine to me, but I don't know why it wouldn't be
15:55 pendingchaos: maybe hakzsam can ACK it?
15:55 hakzsam: I haven't looked carefully, it's !6991?
15:56 jekstrand: hakzsam: yeah
15:56 jekstrand: pendingchaos: I think an ACK in this case is mostly a formality
15:57 hakzsam: yeah, I think it's fine
16:04 jekstrand: pendingchaos: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7509
16:04 gitbot: Mesa issue (Merge request) 7509 in mesa "spirv,nir: Add support for SPV_EXT_shader_image_atomic_int64" [Nir, Spir-V, Opened]
16:04 pendingchaos: thanks
16:54 mslusarz: FYI, I opened MR 408 for piglit, which may help (CI?) people find which shader_runner test caused a GPU hang, if kernel prints process name with a hang information
16:57 jekstrand: mslusarz: Neat. But how do you go from a hash to a test name?
17:00 mslusarz: it's not a perfect solution, but you can create the mapping between hash and a test by running shader_runner on all shader_test files with SHADER_RUNNER_PROC_NAME_CTL=print (it will not execute them, just print the name)
17:01 mslusarz: and if you really hate it, there's SHADER_RUNNER_PROC_NAME_CTL=filename, but unfortunately kernel truncates process name to 15 characters
17:13 ajax: robclark: mmm. probably that's because the dri loader isn't bothering to set the bit to say it's supported?
17:14 ajax: robclark: but also, is that extension really something you need, and can you not adequately work around it by using KHR_context_flush_control?
17:15 robclark: I briefly looked at the that bitmask logic.. and then decided to just hack around it
17:16 robclark: only needed the extension for some multithread piglit tests that I was trying to use to repro an issue I'm debugging
17:17 ajax: should just be https://paste.centos.org/view/02ffd4b4 ?
17:17 MrCooper: I doubt that extension is reliable in general, lots of code in Mesa assumes a context can only be current on one thread
17:21 ajax: the extension assumes the caller only calls into the gl from one thread at a time and manages its own mutex around that
17:21 ajax: so... yes, if you do something it says is undefined, it's undefined
17:21 robclark: yeah, I'm not even sure what uses that extension.. was just something random I noticed because some piglit tests depended on it
17:22 MrCooper: I only know of cairo's defunct GL backend using it
17:22 ajax: admittedly "work around it with KHR_context_flush_control" assumes you can make _every_ context in your process use the no-flush bit
17:23 ajax: cairo-gl's context could be no-flush but switching to it would still punish anyone else using classic flush behaviour
17:32 nchery: Hi, would anyone be interested in taking a look at
17:32 nchery: https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/406
17:32 gitbot: Mesa issue (Merge request) 406 in piglit "gl-3.0/clearbuffer-depth*: Test required clamping" [Tests, Opened]
17:32 nchery: It adds a new testcase to some existing piglit tests
18:02 karolherbst: nice.. pipe_screen API wired up as well :)
18:19 dcbaker[m]: karolherbst: what issues with meson and rust do you still have? It's monday, so I'm ready to start looking at stuff
18:20 karolherbst: dcbaker[m]: cutom_target deps not working
18:20 dcbaker[m]: with bindgen?
18:20 karolherbst: yeah
18:20 karolherbst: https://gitlab.freedesktop.org/karolherbst/mesa/-/blob/rusticl/src/gallium/frontends/rusticl/meson.build
18:21 karolherbst: building rusticl doesn't trigger the bindgen invocations
18:21 karolherbst: might be my fault, but.. couldn't get it to work
18:21 karolherbst: bindgen does seem to regenerate reliably though when I build the target directly
18:21 karolherbst: didn't hit any issues there at least
18:21 karolherbst: (like changing header files)
18:22 dcbaker[m]: Out of curriosity, can you put the generated sources directly in the sources of librustcl, without the intermediate declare_dependency()
18:22 dcbaker[m]: ?
18:22 karolherbst: didn't help
18:22 karolherbst: I think my meson might be too old?
18:22 dcbaker[m]: what version?
18:22 karolherbst: like only the first file get pulled in or so
18:23 karolherbst: 0.55.3
18:23 dcbaker[m]: hmmmmm, okay. That's probably an easy fix, probably can get it backported
18:24 dcbaker[m]: I think I'm going to add a bindgen wrapper to the rust module I've been working on as well
18:25 karolherbst: okay, cool :)
18:25 karolherbst: but besides that the meson stuff seems to work.. just not being able to use external crates is annoying, but I'll try without. Even though there are a few I'd like to use
18:26 karolherbst: ohh right, what about rustfmt? Do you think it makes sense to add that as well or should we wire that up inside mesa?
18:30 dcbaker[m]: there is a clang-tidy target inside meson already (I saw a bug about it), so unless rustfmt is really strange I don't see why not
18:31 karolherbst: does clang-tidy need an additional dep? rustfmt isn't installed by default afaik, but I guess meson could check for that
18:32 dcbaker[m]: I'll have to look to be sure, but I'm sure that the clang tidy integration looks for clang-tidy either at configure time or runtime
18:33 airlied: danvet: btw i reposted multihop forgot to cc you
18:34 danvet: airlied, yeah spotted, hopefully can go through it tomorrow
18:34 danvet: and I'll ignore the = {} bikeshed :-)
18:41 robclark: with ralloc, can I make any threadsafeness assumptions? Ie. it looks like if the a node and it's parent node is not used from multiple ctxs then operations on the child node should be safe, even if the grandparent node requires locking? (Just trying to figure out what to do about multithread situations where you could have shader variants created on different ctx's/threads.. adding locking around *all* ralloc
18:41 robclark: seems a bit overkill when it is only the toplevel shader node that is problematic. (Ie. ir3 creates variants as ralloc child of shader, and then other things as children or grandchildren of the variant)
18:54 jekstrand: robclark: No, you cannot.
18:54 robclark: ugg
18:55 jekstrand: robclark: Well, rather, you should only touch a given ralloc tree from one thread at a time.
18:56 jekstrand: I think, in theory, as long as the current thing and it's parent aren't touched by another thread, you're ok.
18:56 robclark: hmm, or maybe this isn't *that* bad if I add a per-shader lock.. I guess I don't really want to be compiling the same variant in two threads anyways..
18:56 jekstrand: But that seems a bit fragile.
18:56 robclark: yeah, that was the thing I was thinking of.. but a per-shader lock avoids the whole problem, so I think I'll go with that
18:59 jekstrand: Yeah, seems better
19:00 jekstrand: At one point, I considered adding some better thread-safety stuff there.
19:00 jekstrand: Mostly asserts to formalize and keep people from breaking invariants.
19:03 robclark: asserts would be nice.. but at least I managed to come up with a reproducer I can run on linux (ie. w/ valgrind/helgrind)
19:03 robclark: (trying to debug this w/ android apk is super pita)
19:09 anholt: tomeu: when updating lava_build.sh, please always bump the arm64_test too. The amd kmod change broke freedreno, but I got to find when my next ci image build broke.
19:09 anholt: would renaming to lava_and_baremetal_build.sh help?
19:10 anholt:honestly wishes our containers would just hash .gitlab-ci/container/* and include that in the tags. the CI machine time is not worth the human time managing this.
19:14 tomeu: anholt: sorry, I was afraid that could happen and thought I had updated the tag, but I probably lost it while solving some merge conflict
19:14 tomeu: and yeah, thought about the hashing as well
19:15 tomeu: anholt: guess easiest than hashing and better than renaming is to put a comment on the top of each file so one knows what tags need to be updated
19:17 anholt: I haven't found comments like that to be very effective.
19:17 anholt: (as you said, you thought about how you should probably bump the arm64 tag)
19:18 anholt: Also, are you using ARM machines as the gitlab runners? Wasn't there going to be a switch so that we didn't even need separate containers?
19:19 anholt: though I guess the kernel+rootfs thing is a separate job now anyway, so that wouldn't help because we would still have tag duplication.
19:20 anholt: Having to put the job DAG in stages sucks. Wish arm64_test could just reuse kernel+rootfs to build its container, but I don't think it's worth yet another stage in the ui to do so.
19:21 tomeu: yeah, the current setup is what daniels suggested based on the builder availability at that moment
19:24 daniels: shrug, we can go back to using x86 no problem
19:25 daniels: having unified containers would definitely be a huge win, even if it does mean we have to eat some qemu along the way
19:25 daniels: (assuming that fdno+etnaviv baremetal / baylibre lava won't be running on aarch64 hosts anytime soon?)
19:25 anholt: The qemu is pretty short for some package installs inside the chroot, really not much time compared to the rest of the container setup.
19:25 anholt: like, you've got a deqp build in there.
19:26 anholt: you can emulate a lot of stuff in the time it takes to do a native deqp build
19:26 daniels: yeah for sure, hence 'no problem' & 'huge win' :)
19:31 daniels: as you say, the optimisation targets are hard to fuck up + lowest human busywork
19:51 nanonyme: Hi, was it intentional that https://gitlab.freedesktop.org/mesa/mesa/-/commit/431e9abaaba6386aa7fbc1ec0e2566a3f8999f5d started failing build for osmesa=gallium?
20:36 anholt: tomeu: So, if I back out the s/=m/=n/ sed job, a306 probes drm again.
20:37 anholt: This weekend I had tried a local kernel build with that sed job and not reproduced the problem on my local a306.
20:38 anholt: any clues? I'd rather not have yet another knob for our builds to disable this, but I'm many hours into sorting this regression out.
20:41 anholt: https://gitlab.freedesktop.org/anholt/mesa/-/jobs/5484805 <-- rebuild of master's container for arm64, which fails to probe drm.
22:25 karolherbst: airlied: are you aware that we need a proper Device Vendor ID for llvmpipe?
22:45 HdkR: karolherbst: For llvmpipe or lavapipe?
22:46 karolherbst: uhm... Opencl
22:46 karolherbst: so llvmpipe
22:46 HdkR: ah, CL things :D
22:46 FLHerne: Does CL-on-llvmpipe not have a fancy name yet? :p
22:47 dcbaker[m]: I vote for CLnder
22:47 jenatali: I kinda like cloverpipe, since it's CL-over-pipe
22:47 jenatali: But maybe that was the whole point of the clover name in the first place :P
22:47 karolherbst: jenatali: *cough* question is for how long *cough*
22:56 dcbaker[m]: karolherbst: you've actually hit a really hard to solve problem with generated sources, sigh
22:56 karolherbst: :/
22:56 dcbaker[m]: rustc just assumes "this is cargo, and the layout is cargo"
22:56 karolherbst: I am sorry?
22:56 karolherbst: dcbaker[m]: yeah
22:56 dcbaker[m]:is just venting/explaining
22:56 karolherbst: that's why I did the idep thing
22:57 karolherbst: felt more natural
22:57 dcbaker[m]: the problem is that cargo mixes build and source files in one tree
22:57 dcbaker[m]: meson never does that
22:57 dcbaker[m]: I don't think there's a reliable way to make that work without changes to rustc
22:58 karolherbst: talking about the include stuff or the pulling in dependencies thing?
22:58 dcbaker[m]: no, generated files
22:58 dcbaker[m]: errr, generating sources
22:58 karolherbst: keep in mind that I include generated files from rs files within the normal layout
22:58 karolherbst: what I really just need is meson to create dependencies from the rust lib to the custom_targets
22:59 karolherbst: the files itself don't need to be added
22:59 dcbaker[m]: I think you're going to have to compile the generated sources into a crate
22:59 dcbaker[m]: static_library
22:59 dcbaker[m]: thingy
22:59 karolherbst: mhhh
22:59 karolherbst: that I can;t
22:59 karolherbst: *can't
22:59 dcbaker[m]: of course
22:59 karolherbst: the generated rs files are invalid by themselves
22:59 dcbaker[m]: of course they are, sigh
23:00 karolherbst: yeah... working around bindgen :D
23:00 dcbaker[m]: I'll go see what I can do upstream with rustc
23:00 karolherbst: or rather how the CL API is
23:00 dcbaker[m]: it isn't really even a bindgen problem
23:00 dcbaker[m]: it's that rustc is basically an implementation detail of cargo
23:00 karolherbst: that's the wrapper for including the CL bindings: https://gitlab.freedesktop.org/karolherbst/mesa/-/blob/aa31e4ef40d5bdb356d3e0c11839d7f94af2d8b3/src/gallium/frontends/rusticl/api/bindings.rs
23:01 karolherbst: that's the mesa one: https://gitlab.freedesktop.org/karolherbst/mesa/-/blob/aa31e4ef40d5bdb356d3e0c11839d7f94af2d8b3/src/gallium/frontends/rusticl/mesa/bindings.rs
23:01 karolherbst: so things _can_ be valid, but sometimes you need to hack around stupid stuff
23:02 karolherbst: although I guess I could cat the files together or something mhhh
23:02 dcbaker[m]: that's gross too
23:03 karolherbst: I know
23:03 dcbaker[m]: rustc should be able to say "here's my source dir, here's my build dir"
23:03 karolherbst: the annoying thing is, that bindge tells you to do this include which also depends on the OUT_DIR env var
23:03 karolherbst: and rustc picks up the file accordingly then
23:03 dcbaker[m]: meson needs it, cmake needs, it basically every established build system supports and most encourage using out of tree builds
23:04 karolherbst: "include!(concat!(env!("OUT_DIR"), "/bindings.rs"));" like this
23:04 karolherbst: ahh yeah :/
23:05 karolherbst: dcbaker[m]: mhh... rustc has this "--out-dir" flag
23:05 karolherbst: dunno if that helps
23:07 karolherbst: ooh well
23:07 dcbaker[m]: the problem is that our tree is like [build_A <- root -> src_A], rustc expects all of the sources to be in src_A, and there doesn't seem to be a way to say "look over in build_A too",
23:07 karolherbst: mhhh, right
23:07 karolherbst: but that wouldn't solve my problem
23:07 dcbaker[m]: there' isn't an -I flag, essentially
23:07 karolherbst: even if it could
23:08 dcbaker[m]: so your problem is only that the dependency order is incorrect?
23:08 dcbaker[m]: cause I've already fixed that, lol
23:09 karolherbst: well.. there are two issues: 1. meson target deps not pulled in 2. no idea how to include rs files from the build directory without absolute paths
23:10 karolherbst: rust _can_ pull in from relative paths, but they seem to be relative to the original source path
23:10 karolherbst: which is pointless if stuff gets placed inside build dirs
23:10 karolherbst: hence bindgen telling users to use an env var cargo apparently sets on rustc
23:10 dcbaker[m]: could you use a #cfg() directive, and have meson pass an argument to rustc?
23:11 karolherbst: how would that work?
23:14 karolherbst: the only interface we could use for arbitrary data seems to be env variables, but you said ninja doesn't like that?
23:14 dcbaker[m]: could you do something like `let import_path = cfg!(import_path)` and then pass `--cfg import_path="<something meson generates>"` in the meson.build file?
23:14 karolherbst: uhh
23:16 dcbaker[m]: I have no idea if that will work
23:16 karolherbst: no.. cfg is something else
23:17 karolherbst: and it returns true/false anyway
23:18 dcbaker[m]: cfg is for conditional compilation, you can pass values to it, I know you could do things like `#[cfg(target_os = "linux")]`
23:18 karolherbst: yeah
23:18 karolherbst: but the result is bool
23:18 dcbaker[m]: that's too bad
23:18 karolherbst: and it has predefined keys anyway
23:19 dcbaker[m]: you can set your own feature options somehow, crates do it to control features
23:19 airlied: karolherbst: will look into it, for Vulkan they had a separate space that I got lavapipe an id in
23:21 karolherbst: airlied: adaptors can get a special vendor id for CL apparently
23:21 karolherbst: coldplay has one eg
23:22 karolherbst: dcbaker[m]: ahh, okay.. anyway, we don't get a string out :/
23:23 airlied: karolherbst: got a few things to fix before I have to worry too much :-P
23:26 dcbaker[m]: and of course their solution is "use env vars" which ninja simply doesn't support at all
23:27 dcbaker[m]: and has said they will never ever under any circumstances support
23:28 karolherbst: airlied: :D
23:28 karolherbst: dcbaker[m]: sad :/
23:29 karolherbst: so we are already at "there are only bed solutions"
23:29 karolherbst: *bad
23:29 anholt: karolherbst: as a hack, custom target that copies your source file to the build dir, then you custom target with that as the source>?
23:29 dcbaker[m]: you can use configure_file() to copy things
23:30 dcbaker[m]: But I'm not sure what else to do really
23:30 dcbaker[m]: we really should add a "copyfile" method to the meson fs module
23:30 karolherbst: mhhh
23:31 karolherbst: stupid idea: copy all files from the given list to some temporary path inside the build dir and build from there.. *cough*
23:35 dcbaker[m]: that's... pretty much what I came up with too
23:35 karolherbst: huge problem is just the placement of generated files :/
23:36 karolherbst: ahhh, this is so annoying
23:36 karolherbst: but I guess messed up paths might be okay
23:53 dcbaker[m]: https://github.com/rust-lang/rust/issues/78913, let's see what kind of answers I get
23:53 gitbot: rust-lang issue 78913 in rust "Support for generated sources, when building out of tree with non-cargo build systems" [Open]