Martin,

Martin v. Löwis wrote:

Martin v. Löwis <martin@v.loewis.de> added the comment:

Your suggestion for using the CC variable to fix the problem that I 
reported won't work - I already tried it and based on what others are 
reporting, you are beating a dead horse. Believe me I would rather not 
modify anyone's code in order to build something. The problem is that 
the CC variable doesn't fix the link stages


Why is that? It should work fine.

It does not when link stage specific options are required that are not valid for compilation stages.

and overall your autconf 
build is broken particularly as it relates to flowing variables down to 
sub builds.


This I don't understand. What is a sub build?

My mistake. I was thinking of another package - you can scratch that comment.

I don't know why you are resisting this change. I took the time to 
report the bug, proposed a fix /_*and*_/ contributed the patch that 
would make the Python build process more standard relative to the vast 
majority of open source packages that use autoconf.


I don't think that's the case. In autoconf, if you specify CFLAGS,
you expect that this overrides, not adds to, anything configure
computes on its own. This patch does not do that, i.e. it doesn't
allow you to override the settings that configure computes.

There is no hard and fast rule that specifying the CFLAGS or other configure variables have to override all of the compile flags that a developer chooses to use in their build process. Most open source packages use the configure CFLAGS, LDFLAGS, etc, variables to add to the compile and link flags and not completely override them. My patch follows the same philosophy that I have seen in the majority of other open source packages.

I'm concerned that the patch merely makes the entire setup more
complex, rather than solving an actual technical problem. That's
why I'm resisting to accept it.

On the contrary - it does not make it more complex and it does provide a solution to a number of compile and link failures that have been reported over and over again. When I first posted this bug I read through the various forums and bug reports and I noticed quite a bit of complaining regarding this issue and I acknowledged that by noting in my report that what I was opening a bug report on what was clearly a sore subject within the Python community. To be specific the complaints were regarding the symptoms (unusual compile and link problems) related to this issue, not the specific cause of the problem which is why I filed the bug as I did.

The patch that I submitted will allow a build of Python to be performed the exact same way it is today without any modifications to CFLAGS or LDFLAGS, etc. Those of us that need to use these variables will be able to modify the build options to the configure script as necessary without any complexity and without losing 'important' compile options that are currently generated by configure. All of your suggestions to use the CC variable in lieu of using the more appropriate CFLAGS, LDFLAGS, etc., introduce the very complexity and non-standard approach you are claiming you want top avoid.

Again, I don't see what your concerns are. My patch is a completely non-affecting change to the way Python is built today but it does add the necessary fixes so that those that require specific compile and link options can specify them to the configure script.

In addition, while you are fixing the build/compile options, I noticed that you are missing the -fPIC compile option. Without it you can't link shared libraries and the build fails. You should probably be including -fPIC as a standard compile option so it is not required to be passed into the build via the configure script.

---
Bob