16:28 <joseph_> teepee: I will read through the logs. Also, I will try merging in my changes for F6 shaders from last year. With some good luck, that might mean that rendering can work with no legacy calls. Preview will require more work as kintel pointed out. Anyway there is one place in GSoC 2022 I know of that might use client-side vertex arrays far down the stack, but hopefully that is a quick fix.

16:29 <joseph_> On the other hand it may be the case that deprecated functions make up a critical part of the viewport itself. In which case the first step would be more work in that area

16:35 <teepee> joseph_: I think it's ok to look at render first, so if the core-3.2 context is enabled, preview would not work in the first step

16:36 <teepee> we need to find a way to untangle all that legacy mess, so pulling the thread somewhere is probably the only solution

16:36 <teepee> as long as we can keep things such that disabling the core-3.2 enforcement will fall back we are not going into a one-way street

17:22 <joseph_> The macros wrapping legacy code are all ifndef. So the only way that the source code will change is if someone intentionally adds the compiler argument. But, because GLAD is a set of headers generated statically from the command line program, the 3.2-core GLAD files couldn't be merged yet

17:36 <teepee> joseph_: yeah, the #ifdef is clear, I don't mean it to be a dynamic option, just that we could activate the code that works already, when compiling with legacy support it would use a compatibility context

17:36 <teepee> that should be possible with glad too, no?

17:37 <teepee> like dev compile -> enable 3.2 -> preview does not work

17:37 <teepee> user build -> enable legacy -> uses compat context -> preview works using fixed pipeline

17:38 <teepee> my understanding from glad so far is that it generates the entry points selected at generation time but it should be able to run against any subset of what's generated