search

vim / vim-appimage

AppImage for gVim
115 stars 20 forks source link

build_vim.sh: enable py3 (dyn), disable py2 #70

Closed mralusw closed 6 months ago

mralusw commented 6 months ago

It would be possible to keep py2, however the documentation states that Vim "imprints itself" on whatever the user happens to run first (py2 / py3) and then crashes if the other version is requested. That doesn't sound like great behavior; plus py2 has been deprecated for a long time and Debian / Ubuntu also disable it.

I've discussed the pros of using interp=dynamic and the requirement to set pythonthreedll in #69 — this can be documented later.

mralusw commented 6 months ago

Also see #62 (which should be re-opened, because the fix actually disabled python3)

chrisbra commented 6 months ago

ah thanks for that!

mralusw commented 6 months ago

The apt installs in release.yml might need to change from python-dev python3.8-dev to just python3-dev. This is what I've tested with in my fork. But hopefully the build will work, as it looks like it used to work before 39f585d.

chrisbra commented 6 months ago

It seems to have failed however :/ https://github.com/vim/vim-appimage/actions/runs/8563313286/job/23468151744

mralusw commented 6 months ago

That's not good. One difference is that I've always built on Ubuntu 22.04.

I've made another fork to test various versions on 20.04.

It seems there's a problem with py3/dyn on 20.04 (but not on 22.04 — I've been testing that for a few days now). If I revert to non-dynamic python3 (i.e. undo both the older 39f585d and the recent PR), it builds (workflow), but the git commit breaks in the end (probably mismatched tags, anyway not related to the build).

We might have to go back to py3 non-dynamic. This means no stable ABI, an embedded lib just like the other interps have, and (unless user runs 20.04) no access to the site modules py3 needs to boot up. Basically as far as Py is concerned, it would remain a 20.04-only image.

At some point you could add a matrix to the GH workflow, meaning it could build on both 20.04 and 22.04, with different configutations.

chrisbra commented 6 months ago

Perhaps this is an issue for vim/vim ? Ping @ychin any idea about this failure?

f_py_both.h: In function ‘ListItem’:
if_python3.c:297:24: error: dereferencing pointer to incomplete type ‘PyTypeObject’ {aka ‘struct _typeobject’}
  297 | # define PySlice_Type (*py3_PySlice_Type)
      |                        ^~~~~~~~~~~~~~~~~
/usr/include/python3.8/sliceobject.h:31:44: note: in expansion of macro ‘PySlice_Type’
   31 | #define PySlice_Check(op) (Py_TYPE(op) == &PySlice_Type)
      |                                            ^~~~~~~~~~~~
if_py_both.h:2743:14: note: in expansion of macro ‘PySlice_Check’
 2743 |     else if (PySlice_Check(idx))
      |              ^~~~~~~~~~~~~
gcc -c -I. -Iproto -DHAVE_CONFIG_H     -Wno-deprecated-declarations  -D_REENTRANT -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1        -o objects/netbeans.o netbeans.c
make: *** [Makefile:3300: objects/if_python3.o] Error 1
make: *** Waiting for unfinished jobs....
mralusw commented 6 months ago

I think the GitHub infra has some issues at this moment, it says "can't retrieve commits", and the git push error I got for the workflow seems to be associated with GH problems, as far as internet wisdom says. Or maybe they got tired of my experiments :(

mralusw commented 6 months ago

Huh. It builds, and it reports itself (:version) as +python3/dyn, +python/dyn, even though --enable-python3interp was simple, not =dynamic, and no stable-abi was requested... This is good, but unexpected

The #ifdef'd code in vim src/if_python3.c depends on 4 things, and the interactions are not really clear at all