It does not when link stage specific options are required that are not valid for compilation stages.Martin v. Löwis <email@example.com> 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 stagesWhy is that? It should work fine.
My mistake. I was thinking of another package - you can scratch that comment.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?
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 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.
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.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.