Some packagers might want to disable ABI flags. The attached patch adds --disable-abi-flags option to `configure`.

I think this is not a good idea, because then you have different names for extension modules, which will be recognized by one configuration but not the other.  This configure option should not change the sonames.  If this option is to keep pathes like /usr/local/include/python3.2 (instead of /usr/local/include/python3.2mu) or /usr/local/lib/python3.2/config (instead of /usr/local/lib/python3.2mu/config), then fine with me. Although in this case we should make sure that these pathes are available in the sysconfig module.

What specifically is the motivation for this option?  Since abiflags are used in many places, most of which are hidden from the end user, why are they a problem, and what are the use cases for suppressing them?

If it's to eliminate the abiflags in the binary names, then I can get on board with that.  (IOW, instead of symlinking python3.2 -> python3.2dmu, just write out python3.2 and avoid the extra symlinks).

Please clarify.

I want to eliminate ABI flags in file names.

I agree with the intent: package maintainers, or people compiling python for their own need, should have the right to choose the suffix used by extension modules.

I suggest another option though, one that directly sets the SOABI used in extension file names. This would override both the default SOABI (python3.2) and the flags added to it.
For example, when no flag is passed to ./configure, the default is equivalent to 
    --soabi=cpython3.2m
And we can get the 2.x naming scheme back simply with:
    --soabi=
Yes, this flag should be only used when you know what you are doing.  This builds a version of python that will be unable to load extensions built by other people.

I still fail to see the rationale for being able to build with a different soabi name.  But anyway, as long as the default is to build with the soabi name, I'm +/-0 on this option.

Note that the soabi name isn't fixed but changes with other configure options.

> Note that the soabi name isn't fixed but changes with other configure options.
The default value, yes.
But my proposal of a --soabi option would not respect this. The caller is responsible for changing the --soabi value when he adds other options.

+0 for Amaury's suggestion in msg122792.  Who wants to write that patch?  I'd happily review it.

Here is a first patch that adds the "--with-soabi" option.
    --with-soabi=yes or --with-soabi  sets SOABI to the computed value (cpython-32m when I tried it). This is the default behavior on Linux.
    --with-soabi=no or --without-soabi  sets SOABI to the empty string, and removes the additional searched extensions from imp.get_suffixes().  This is the default behavior on all other platforms.
    --with-soabi=<tag>  sets SOABI to the given string.  Then imp.get_suffixes() contains the following extensions: [".tag.so", "module.tag.so", ".so", "module.so"]

The patch is not yet complete, it does not modify the suffixes in the dynload_* files for platforms other than Linux.
Windows support will come after. It requires more thoughts because there is no Makefile to read at runtime.

But it's the first time I change the ./configure script, so please comment on this first patch.

Of course, you don't change configure directly, you change configure.in and let autoconf update the configure (but you already know that I'm sure :).

The patch looks fairly reasonable, though I haven't tried it.  One question: does $SO have the same value after your patch as before?  That's a variable available via sysconfig and it looks like you're removing a block of code that sets it.

The value of get_config_var("SO") is the same as before, something like ".cpython-32.so" by default on Linux. (see, I just moved the line SO=.$SOABI$SO at the bottom of the patch).

In the C file dynload_shlib.c, I chose the names SO_BASE for the "simple" extension (.so) and SO_EXTRA for the "decorated" extension (.cpython-32.so)

Is there a way to write unit tests for all this? This would prove that the default behavior is the same as before.

On Nov 30, 2010, at 10:12 PM, Amaury Forgeot d'Arc wrote:

>The value of get_config_var("SO") is the same as before, something like
>".cpython-32.so" by default on Linux. (see, I just moved the line
>SO=.$SOABI$SO at the bottom of the patch).

Cool, thanks.

>In the C file dynload_shlib.c, I chose the names SO_BASE for the "simple"
>extension (.so) and SO_EXTRA for the "decorated" extension (.cpython-32.so)

Since I used SOABI earlier, what do you think about SOBASE and SOEXTRA for
consistency?

>Is there a way to write unit tests for all this? This would prove that the
>default behavior is the same as before.

It would, but I couldn't think of a way to do that reliably across platform.

Let's test Linux at least, then.

What's the status of this?  It sounds like it something that should be taken care of before the 3.2 release, but I know there has been other activity in this area and I haven't looked closely enough to understand the issues involved.

shouldn't that option work on platforms too, which currently default to not using the soabi?  It would make sense for all posix, and macos, maybe not for Windows.

The soabi tag could be useful on Windows as well, for example if some package maintainer chooses another version of the compiler, or a custom version of MSVCRT.

And FWIW, PyPy currently uses "--soabi=pypy-1.4" on all platforms: "import foo" will load foo.pypy-14.so (foo.pypy-14.pyd on Windows). There are also some specific abiflags. A difference is that PyPy will also ignore the default foo.so, because extension modules built for CPython will likely crash with PyPy.

Amaury, did you see my suggestion re $SOBASE and $SOEXTRA?

Also, do you think you can write some tests, even if they only run on a single platform?

I suspect the Makefile.pre.in part of the patch will have to be updated now.

Please be sure to test your changes with --enable-shared as well to make sure everything gets installed correctly.

I think we've had plenty of time to adjust to the abi tags.  Does anybody think that nearly 3 years later anything really needs to be done here?