<antocuni>
does anybody have a clue and/or have a mac to try?
<mattip>
give me a few minutes to get set up
<antocuni>
thanks
<antocuni>
I assumed that somewhere on the internet there were a rosetta stone of how to use the various __attribute__ in various compilers but it seems it doesn't exist
<antocuni>
basically, in CPython and Hybrid mode we use the "real" types which comes from Python.h
<antocuni>
in universal mode we create fake cpy_* types
<antocuni>
we need them because e.g. we need a type for HPyModule_Spec.legacy_methods
<antocuni>
but since they are only forward declarations it means that it's impossible to instantiate them, and so in practice it's impossible to use .legacy_methods=...
<antocuni>
and btw this is a much better approach than what we have on master; on master, we have "typedef struct _object cpy_PyObject", but this works only as long as CPython calls its struct _object
<antocuni>
and I think that we were going to have problems with CPython 3.11 because they changed/removed some of these struct names
<mattip>
ok, so what kind of error do you get in universal mode when the compiler tries to instantiate a FORBIDDEN_cpy_PyObject ?
<mattip>
maybe that error is good enough?
<antocuni>
not really useful
<antocuni>
"storage size of 'myvariable' isn't know"
<antocuni>
but note that you really have to try hard to arrive at that point
<antocuni>
also, allocating a PyObject on the stack doesn't really make sense, you always want a pointer to it
<antocuni>
but I think that the most important thing is that if you use PyObject or PyMethodDef you get an error because they are not defined
<antocuni>
so then the next thing you would do is to #include <Python.h>
<antocuni>
and then you get a nice error which tells you that you cannot use Python.h in universal mode
<mattip>
hmm. Like most enhandements, I think it is fine to put in a first version of this PR, and then polish it when others can try it out in their workflows
<mattip>
without trying to solve all the problems at once
<antocuni>
yes
<mattip>
especially if we let it mature before a release
<antocuni>
also, all of this is to be really nice to people
<antocuni>
but in theory it's enough to say in the docs "if you target universal you cannot include Python.h and if you do, it's your fault"
<mattip>
+1
<antocuni>
ah, I think I know why clang doesn't work
<antocuni>
the documentation which I linked to is for clang 16
<mattip>
well, you could add a __GCC guard if you really really want that feature
<antocuni>
it seems that clang has a __has_attribute macro check
<antocuni>
I'm experimenting with it
<antocuni>
btw, I've discovered the very handy command "gh pr chekcs"
<antocuni>
*checks
<antocuni>
it shows the github jobs for the current PR directly in the terminal (with a green/yellow/red icon depending on the status), without having to use the browser
<mattip>
cool
<antocuni>
fangerer: if you have access to windows, could you please help me PR 371? I keep getting windows errors and fixing them blindly is not working