@Perksey What do the ConstAny and Any types map to with the new types?
@Perksey What do the ConstAny and Any types map to with the new types?
Pthey’re equivalent to the non-generic ones
Cokay that's what I thought. What are the generation steps, I need to regenerate GLFW.
Pshould just be a case of running SilkTouchX with the test.json path as an argument (oh and add “—skip Windows” or whatever it’s called in test.json, as that will take forever
Cokay got it running but it didn't generate anything
P-l debug?
P(you could also do trace but that may be excessive)
Cin either case it just looks like it is doing no work
C
Phmmm, do you have submodules initialised
Cyup
Pmaybe crank it up to trace?
Cthat is on trace
Poh
Pthis is so strange
PI mean it’s probably a case of ClangSharp not running
Pbut how it gets to that point is a mystery
Cokay I guess I'll go down the debug rabbit hole and see if I can figure out what's going wrong
Punless it’s to do with the working directory. I tried my best to make it read relative to the file but may have missed a few places
Cyeah so I'm definitely missing the clang response file
Pwait is that not in the repo?
Cnope
CI don't have any changes from yesterday, but it doesn't seem like any of that should affect this
Ppushed them up, looks like they were gitignored
Cfor future reference, is there a way to generate those response files on my end?
Pthey're not generated, they're hand-crafted
Pi don't know why they're called response files, but basically they include the command line arguments that are passed to ClangSharp's P/Invoke generator
Cokay
Cstill not generating, doesn't look like it is finding the response file
Pare you running in the SilkTouchX dir (the same dir as the test.json)? this shouldn't be required, and if this works then that's a bug i need to fix
Cno I'm running from the VS output directory (in the artifacts folder)
Pahh, give running in the test.json dir a go, if that works then i need to fix that because ideally it'd do everything relative to the config file in question
Cthat did work, note I did get a critical error from the clang scapper about stddef.h not being available
CIt also looks like I lost everything in the glfw3 folder when it regenerated
Cwhoops might be my setup, I didn't install C++ workload
Pon a scale of 1 to 10 how easy was it to figure out that that’s the issue
PI’ve been trying to improve that
Cpretty easy once it was going. There was a message I just had to read through the log.
CShort of stopping there and going in big red text, I don't think it could be much more clear
Cso if 1 is easy and 10 is hard, probably like a 2 or 3
Pawesome, glad about that
Pgiven that this is intended to be consumable by people who aren’t Silk.NET maintainers I’m trying to make it as usable as possible!
CIt may be worth stopping at that step then. Just so it is crystal clear and they don't get half baked output
CSo far, looks like the pointer types are up and running. Some changes had to be made to fix the fact that some names changed, but otherwise I've got it building. I'll run the tests and then hopefully have a PR up in a little bit
Lsaving this list so i know what to update
Lim not sure what this means, do we git-version some of our native packages?
Psee
common.props, there's logic in there that gets the date of the most recent commit in the submodules and uses that for the versionLoh
Pbut i have a feeling that hasn't been working as we'd intended for a while given that we don't clone the submodules in CI haha
Li think if we
git submodule init all of them but not update them i think that would work?Pshould do, just make sure we don't init recursively