update to 4.2.0 on pypi

[jschueller]

currently its still 4.1: https://pypi.org/project/swig/

[nightlark]

Thanks for the heads up - seems my change to make the new swig release checks not mess up with pre-releases, also made it not detect the actual release. 😅

I’ll deploy wheels for the new version soon.

[nightlark]

It looks like it might be a bit more involved than anticipated -- the minimum version requirement of bison 3.5 means that the default version in the CI builder image (2.3) is too old, and of course the code to build a newer bison is giving build errors ostensibly related to a typedef in the standard library. 😕

[jschueller]

hello, any progress on this ?

[nightlark]

I'm still blocked by needing to get a newer version of bison on the (probably pretty old version of) Linux Docker container used by cibuildwheel. Or coming up with a patch to make so that bison isn't needed for the build. This is what the errors look like, if you've got any thoughts on the cause. The best guess I have at the moment is maybe the compiler/c++ standard library in the Docker container are too old.

          CC       lib/libbison_a-fopen.o
        In file included from ./lib/stdio.h:33:0,
                         from lib/fopen.c:26:
        /usr/include/stdio.h:46:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'typedef'
         typedef struct _IO_FILE FILE;
         ^
        lib/fopen.c:29:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'static'
         static FILE *
         ^
        lib/fopen.c:29:1: error: unknown type name 'FILE'
        In file included from ./lib/stdio.h:33:0,
                         from lib/stdio.h:43,
                         from lib/fopen.c:38:
        /usr/include/stdio.h:171:1: error: unknown type name 'FILE'
         extern FILE *tmpfile (void);
         ^
        /usr/include/stdio.h:181:1: error: unknown type name 'FILE'
         extern FILE *tmpfile64 (void);
         ^

I think my ideal choice would be breaking the dependency bison -- the issue at the moment is even though the latest version of swig has a pre-generated source file, the CMake build system requires bison (tbh, this seems like something that should be easy to change and hopefully get into the next swig release).

Or making a gnu bison PyPI package available with a modern version of bison pre-compiled for all major OSes, that could then be specified as a "build system" requirement in pyproject.toml

[jschueller]

which image are you using ?

[nightlark]

It looks like quay.io/pypa/manylinux1_x86_64:2023-10-01-4095a57 is being used by the CI job that fails first.

[jschueller]

this one is deprecated, maybe you can try to switch to manylinux2014 to get a bit more recent compiler ?

[nightlark]

That would be nice -- I'd like to try to keep things working for as many people as possible, so if it works I'd favor bumping it to manylinux2010 instead.

It's hard to estimate exactly how many will be impacted by dropping manylinux1, based on https://mayeut.github.io/manylinux-timeline/ I think the takeaway is that even users on Python 2.7 are almost all running systems at least compatible with manylinux2010 in terms of glibc version, but I guess the version of pip installed only recognizes manylinux1 platform tags.

[jschueller]

its very reasonable to drop 2.7 knowing it was discontinued years ago

[nightlark]

That’s the most extreme example, but even Python 3.7 which was EOL recently has a surprising portion of users with a pip version that only recognizes manylinux1.

[nightlark]

It looks like swig 4.2 also broke something (fortunately not Bison related) in the macOS builds.

[jschueller]

what is the error message ?

[jschueller]

btw I tried to build bison on manylinux1 and got no errors:

FROM quay.io/pypa/manylinux1_x86_64
MAINTAINER jschueller

ENV MAKEFLAGS -j8
WORKDIR /usr/local/src

RUN yum install -y zlib-devel xz xz-devel pcre-devel zip wget bzip2-devel openssl-devel mpfr-devel libmpc-devel

RUN curl -fsSL https://ftp.gnu.org/gnu/bison/bison-3.8.2.tar.gz | tar xz && cd bison-3.8.2 && ./configure && make > /dev/null 2>&1 && make install > /dev/null 2>&1 && cd - && rm -r bison*

RUN bison --version
bison (GNU Bison) 3.8.2
Written by Robert Corbett and Richard Stallman.

[nightlark]

what is the error message ?

/Users/runner/work/swig-pypi/swig-pypi/_skbuild/macosx-10.9-x86_64-3.9/cmake-build/SWIG-src/Source/Modules/javascript.cxx:1428:13: error: use of undeclared identifier 'nullptr'

Which sounds like maybe the right C++ standard isn't being set.

[jschueller]

yes, maybe this patch can be applied:
swig/swig@472e9dd

[nightlark]

Interesting -- I bumped the version of bison to build from 3.7 to 3.8.2 like you used, and now bison builds without errors.

Now the Linux builds are giving the same error as macOS (despite setting CMAKE_CXX_STANDARD to 11, huh). It looks like gcc 4.8 supports nullptr, so it seems like the patch shouldn't be needed -- but good to know it exists as a fallback.

[jschueller]

maybe your cmake version is too old, but you might still be able to add -std=gnu++11 to CXXFLAGS manually

[nightlark]

All the builds should be using around CMake 3.21 (specified in pyproject.toml).

Good news, Linux builds work now. Bad news is, Windows is failing too due to recent GHA VM changes, but the fix looks easy (bump cibuildwheel version): pypa/cibuildwheel#1740

[nightlark]

Enabling CMAKE_CXX_STANDARD_REQUIRED fixed the macOS issue (AppleClang is weird).

The emulated Linux builds for manylinux are still running as of now, but it looks like all the build issues might be fixed now🤞

If the PR build passes I expect to have wheels for swig 4.2.0 published within the next day.

[nightlark]

The 4.2.0 wheels should be up on PyPI now -- let me know if you run into any issues with the uploaded wheels. Hopefully things just work for the next swig release!