Ooooh so close! Got the right clang bits in place, patched out a broken part of upstream's build config, the build burns 100% CPU for a while... and then craps itself because it can't find libstdc++ headers. So close!...
Unfortunately those failures still happen in the horrible morass of the custom C++ bindings generator, so simply adding libstdc++ to the build environment does fuck all. Oh well, back to spelunking the source code...
Okay so turns out the C++ binding generator thing makes some hardcoded assumptions about the location of C++ include files, which turn out to not be true in nix's strange build env. So, I need to figure out how to hand it the right include paths, which I do have here in my hand somewhere...
Now of course the annoying part of this is that the binding generation only fails after 30s of burning 100% CPU (because of course python, so it only uses one hyperthread out of 32). So, my iteration time to debug has taken quite a hit.
So very close. I know how to give it the extra include paths, I know which includes I'm missing, the remaining challenge: where the fuck did nixpkgs hide the includes for libstdc++
You would think stdenv, which I'm building from, would provide the C++ base libraries. I certainly thought that. Seems to be a stupid thought to have though, because they ain't here.
Christ on a bike. Right. The magic package is gcc-unwrapped, because of course gcc is not gcc, it's a pile of non-euclidean shell scripts that pretend to be gcc and try to make things work like on FHS computers.
One final hurdle, I need to pass the subpath include/c++/v1 as the include path, which means patching the cmake config.
Really bringing the "no esteemed deed is commemorated here" to the evening with trying to panel-beat all of python and gcc and clang and glibc into playing nice with each other.
What is here was dangerous and repulsive to us. This message is a warning about danger.
tbh that might have to be the PR description when I finally get any of this to work.
Please don't ask me what that guttural noise does, I have no idea. This is the manual's suggestion of what a "more simple" expression might look like, to solve a problem that... I think is the one I have? But I genuinely cannot tell.
Well either way it doesn't matter, whatever these generator expressions are, they literally do not work. The gobbledigook gets passed verbatim to the command being run instead of being expanded.
Okay, absolutely incredible. To join a list, you have to say list(JOIN your_list "joiner str" output_var_name). Okay, baroque, but okay.
But what if you want to split a string, say on spaces, back into a list? Well, naturally, you say string(REPLACE " " ";" output_var your_string)
What?
Apparently cmake treats semicolons in strings as list element separators? So if you materialize semicolons in your strings it magically turns into a list?
I cannot tell if this is a joke. Am I being pranked
I... I think it's working? Maybe? I've added so much debug spam to the generator that I can't see if anything else is going wrong, but it's burning 100% CPU for a very long time now?...
"warning: pragma diagnostic pop could not pop, no matching push"
Now clang's just telling me things like this, which... I think are as close as it gets to being happy? It's currently not rubbing sand into my eyes, and I take that as a win.
Oh god, I didn't realize, the binding generator tool has a progress bar thing, which only gets displayed when it's printing diagnostics.
According to that, and I hope it's wrong, it's planning to take 30 minutes to generate python bindings? Wow those bindings are going to be an absolutely unhinged ride, I can feel it.
dummy.cxx:12:1: error: unexpected character <U+FEFF>
oh god oh no no no no
I hate that I recognize the fucking UTF-16 byte order mark, because it's hurt me so much before.
Please don't fail to generate bindings because of that. Please. I do not want to have to go and figure out how the fuck a BOM rune is sneaking into this.
In other bad news, since it printed a diagnostic, I got a progress bar update. And yup, it wasn't joking earlier, it still thinks it will take 30 minutes to get through this.
So yeah, look forward to having to sit through that every time I need to incrementally debug the next build step that fails.
@danderson I'm putting my money on there being no actual generator program at all, the whole thing is just a horrible template metaprogram that generates the output as a side effect of compiling the "generator". 🍿
@creachadair I would not even be surprised at this point. I've been hurt too much. But, in the binding generator, I think I saw a jinja2 template (lol) and at a glance it seemed like just a normal amount of occult C++, not the kind that would punch a hole into the Dungeon Dimensions.
@DanielaKEngert According to the diagnostic, this BOM rune does not occur at the beginning of a file. So, technically, I guess it's not a BOM, it's a random invalid rune hiding in the source code.
@DanielaKEngert Yes. Except the input, if I'm reading the generator right, is the include files for the OpenCascade CAD kernel. If one of the headers didn't compile... surely someone should have noticed by now?!
I'm hoping this doesn't affect the generation of these bindings, so I can go figure it out as a separate fun mystery later.
@DanielaKEngert Yup, you guessed it. I got bored waiting for codegen. One include file in OpenCascade has a UTF BOM at the start of the file. This binding generator prepends a slug of includes and pragmas to the source before giving it to clang for parsing. So, it shifts the BOM into the "middle" of the file and then clang fails.
I guess I need to figure out how to send a patch to OpenCascade now...
Add comment