homepage

When compiling Python 3.3.1, I noticed that some variables like LDFLAGS or CFLAGS in sysconfig have some flags multiple times. (Which BTW breaks distutils.tests.{test_sysconfig_compiler_vars,test_sysconfig_module}) This is caused by interpretation of Makefile in sysconfig._parse_makefile(), which seems to evaluate the variables in Makefile - but some variables in Makefile are formed by expanding env variables multiple times, e.g.:
PY_LDFLAGS= $(CONFIGURE_LDFLAGS) $(LDFLAGS)
CONFIGURE_LDFLAGS= @LDFLAGS@
so when doing the build from scratch with configure & make, PY_LDFLAGS gets the content of LDFLAGS twice (as far as I remember autotools...), CFLAGS gets expanded like 5 times at least.
I think that this is not the correct behaviour, but not sure, maybe I'm doing something wrong.
Thanks.

There definitely are configurations where some values do get duplicated in CFLAGS and LDFLAGS. In my experience this is generally harmless for builds but, as you point out, it can break tests that expect particular values. It would be nice to clean this up.

I'm attaching a patch that I'm currently using to solve this. It works, but it's a bit aggressive - in the sense that it only adds a string to the sysconfig variable iff this string is not a substring of current variable value. So it may corrupt some values, e.g. it wouldn't add "python" to variable if that variable already had "/usr/lib/python". But it seems to get all the values just fine for me.

Another solution may be to make the test more relaxed and regard the value returned by sysconfig.get_config_var() as a _set_ of shell tokens, whose elements may occur more than once, e.g.
 def test_sysconfig_module(self):
 import sysconfig as global_sysconfig
 from shlex import split
 self.assertEqual(
 set(split(global_sysconfig.get_config_var('CFLAGS'))),
 set(split(sysconfig.get_config_var('CFLAGS'))))
 self.assertEqual(
 set(split(global_sysconfig.get_config_var('LDFLAGS'))),
 set(split(sysconfig.get_config_var('LDFLAGS'))))

The patch doesn't look good to me. If the value contains "-lfoo-lbar $(name)" then substituting name="-lfoo" or name="-lbar" doesn't work.

I don't think that the attached patch is correct. See attached install.diff: difference without/with 00178-dont-duplicate-flags-in-sysconfig.patch on Python installed in /usr/bin/python3.
Example of bug:
 'TESTRUNNER': 'LD_LIBRARY_PATH=/builddir/build/BUILD/Python-3.7.1/build/optimized '
- './python '
- '/builddir/build/BUILD/Python-3.7.1/Tools/scripts/run_tests.py',
+ './python /Tools/scripts/run_tests.py',
The /Tools directory doesn't exist :-/
> I think that this is not the correct behaviour, but not sure, maybe I'm doing something wrong.
Technically, it's perfectly fine to pass the same flag multiple times. It's common to pass -O0 -Og to gcc for example: gcc uses the last -O option value (which overrides the previous ones).
--
This patch is used in the python3 package of Fedora:
https://src.fedoraproject.org/rpms/python3/blob/master/f/00178-dont-duplicate-flags-in-sysconfig.patch
Patch added by:
commit 58f477b403222ea6c13d5d7358551b606cddc0f8
Author: Bohuslav Kabrda <bkabrda@redhat.com>
Date: Wed Apr 10 14:30:09 2013 +0200
 Updated to Python 3.3.1.
 
 - Refreshed patches: 55 (systemtap), 111 (no static lib), 146 (hashlib fips),
 153 (fix test_gdb noise), 157 (uid, gid overflow - fixed upstream, just
 keeping few more downstream tests)
 - Removed patches: 3 (audiotest.au made it to upstream tarball)
 - Removed workaround for http://bugs.python.org/issue14774, discussed in
 http://bugs.python.org/issue15298 and fixed in revision 24d52d3060e8.
https://src.fedoraproject.org/rpms/python3/c/58f477b403222ea6c13d5d7358551b606cddc0f8?branch=master 

build.diff: Difference without/with the patch on Python build from source.
Example:
-	CPPFLAGS = "-I. -I./Include"
+	CPPFLAGS = "-I. -I/Include"
This change is wrong: /Include directory doesn't exist.
Another example:
-	LIBPL = "/usr/local/lib/python3.8/config-3.8dm-x86_64-linux-gnu"
+	LIBPL = "/usr/local/lib/python3.8/config-dm-x86_64-linux-gnu"
I don't understand why "3.8" is removed from the path.

The patch is wrong. I'm not sure when/how C flags are duplicated. Anyway, it seems like the issue is somehow outdated or even gone, so I close the issue.