Creates python-config.sh which aims to behave exactly the same as python-config except it doesn't depend on a Python interpreter on the build machine (only depends on a posixy shell, tested with bash, dash, MSYS-bash).

I use this for cross compiling gdb with Python pretty printer support.

Earlier, we had the shell script, now we have the python implementation, which doesn't work for cross builds. On the other hand, I don't like to have two implementations which need to be kept in sync.

So my proposal would be to discard the python implementation in favour of the shell implementation, provided that it works on all platforms (don't know about windows).

just did see that the patch doesn't support --configdir for 3.3.

I agree in principle about not having to maintain two implementations but I would worry about breaking external packages that depend on the python implementation.

In the meantime, please find an updated version of this patch that adds support for --configdir

I also checked the Windows releases and python-config isn't included. However, I don't think there's a good reason for that. python-config would in theory work fine if people wanted to link their programs to Python on Windows, as would python-config.sh given a posix-y shell that e.g. Cygwin or MSYS provide.

see issue #1161914 for the original script.

> 2) Since we are Pythoneers, why write this script as a
> shell-script instead of a Python script? (sh may not even be
> available on Windows).

python-config is usally not used by python module builds, but third party build systems. When cross-building these packages you usually are unable to run the python interpreter for the target.

Georg, Martin, do you have any opinion if we should replace the python code with shell code (if it works on all targets), or if it should be added as a separate script?

Ray, some issues:

 - is `local' available in all shells? just avoid it.

 - is there a need for the built vs. installed prefix?
   this is logic not found in the python implementation.
   what is this supposed to do?

 - LDLIBRARY and LDSHARED are expressed in terms of Makefile
   macros, leading to syntax errors.

 - --includes doesn't include the plat specific include dir

 - abi flags are missing from the include and lib dirs.

Please recheck, and compare the output of the python implementation with the one of the shell implementation.

> is there a need for the built vs. installed prefix?
>    this is logic not found in the python implementation.
>    what is this supposed to do?

You are right, it is not found in the original python implementation, but I feel that it's useful. Without it, you couldn't give someone a -devel style precompiled Python archive that they can extract where-ever they want and embed in other software without requiring them to install it to the same prefix used during the build process.

> is `local' available in all shells? just avoid it.

I can't be sure about all shells, but local is *very* well supported (bash, dash, csh); I'm happy to remove it though as it's not necessary.

> LDLIBRARY and LDSHARED are expressed in terms of Makefile
>   macros, leading to syntax errors.

This shouldn't be the case, see:

# Replace makefile compat. variable references with shell script compat. ones; $(VAR) -> ${VAR}
+	sed -e "s,\$$(\([A-Za-z0-9_]*\)),\$$\{\1\},g" < Misc/python-config.sh >python-config.sh

> - --includes doesn't include the plat specific include dir

You are right, I will correct this oversight.

> - abi flags are missing from the include and lib dirs.

ABIFLAGS propagates through other variables, namely LDLIBRARY and LDVERSION, but again, there are some issues for me to fix with this.

I will write a new part on my build script that compares the output from the shell script with that from the python script and post a new patch when they agree 100% on all my test platforms.

Am 07.11.2012 13:52, schrieb Ray Donnelly:
>
> Ray Donnelly added the comment:
>
>> is there a need for the built vs. installed prefix?
>>     this is logic not found in the python implementation.
>>     what is this supposed to do?
>
> You are right, it is not found in the original python implementation, but I feel that it's useful. Without it, you couldn't give someone a -devel style precompiled Python archive that they can extract where-ever they want and embed in other software without requiring them to install it to the same prefix used during the build process.

hmm, but python.pc, _sysconfigdata.py and Makefile still have this information. 
How would you test the output and compare it with the python implementation?

>> is `local' available in all shells? just avoid it.
>
> I can't be sure about all shells, but local is *very* well supported (bash, dash, csh); I'm happy to remove it though as it's not necessary.
>
>> LDLIBRARY and LDSHARED are expressed in terms of Makefile
>>    macros, leading to syntax errors.
>
> This shouldn't be the case, see:
>
> # Replace makefile compat. variable references with shell script compat. ones; $(VAR) -> ${VAR}
> +	sed -e "s,\$$(\([A-Za-z0-9_]*\)),\$$\{\1\},g" < Misc/python-config.sh >python-config.sh

ahh, ok, only looked at the file in the build location.

>> - --includes doesn't include the plat specific include dir
>
> You are right, I will correct this oversight.

maybe should only be included, if it's different.

> hmm, but python.pc, _sysconfigdata.py and Makefile still have this information.

In my experience, as long as PYTHONHOME is set correctly before the Python .so, .dll or .dylib is loaded then everything works correctly.

From what I've seen, .pc files are also useless for the purposes of a relocatable -devel package as there's no capability for relative directories in pkg-config.

> maybe should only be included, if it's different.

Ok.

I've addressed everything (local, ABIFLAGS) except the platform includes.

AFAICT, platform includes only differs from includes during the Python build phase. This script can only be run post-install.

I also added --extension-suffix, tidied it up and allowed it to return multiple values in a single invocation, as per the Python script.

looks fine, just one more minor issue: please use @LIBPL@ directly.

there's no feedback from others, so I think this should go in as the extra script first, and not replace the original one immediately.

oh, the equivalent for

        flags = ['-I' + sysconfig.get_path('include'),
                 '-I' + sysconfig.get_path('platinclude')]

is still missing. I know that both scripts versions are only run post-install, but let's have the same output.

background: I'm (mis)using this for a Debian/Ubuntu multiarch installation.

New patch attached:

LIBPL changed to a more direct AC_SUBST and PLATINCDIR used for --includes and --cflags.

so here is what I intend to commit.

 - --help now does exit with 0 (same as the python script)
 - removed the abi safety check (always compares the same
   two strings)
 - build the script for the build target, so that it can be
   checked before installing it.
 - install the old script in $(LIBPL). Maybe we can remove
   this later, or add this functionality into sysconfig.

Great. My only query is whether the changes to sed will work on non-GNU sed.

It used to be like:
sed < in >out

you've now got:
sed in >out

I'm not saying it won't work, I'm not in a position to check, but I think it's safer to keep it as it was.

New changeset c0370730b364 by doko in branch 'default':
- Issue #16235: Implement python-config as a shell script.
http://hg.python.org/cpython/rev/c0370730b364

now committed, using stdin for sed.

Thank you Matthias!