MSVCCompiler: Fix for feedback loop in os.environ[] #7926
Conversation
Each time an MSVCCompiler is instantiated, os.environ['lib'] and os.environ['include'] doubles. This leads to hitting the 32,768 character limit.
|
you could just do also the joining should probably be |
|
Be good to get this finished up. |
|
Sure thing, I'm just a little busy at present. Feel free to reject mine in favour of a better version from @juliantaylor, if Julian has more bandwidth. |
|
@mingwandroid Out of curiosity, how did you manage to get to the 32,768 limit? I think EDIT: Ah, I see that |
|
I don't see why the environment should be updated in any case, only @juliantaylor @cgohlke Thoughts? |
|
@dzagorny These classes are yours. What is the reason for the |
|
Compiling numpy itself with an initially quite large os.environ['include'] hits it for me. It seemed to me that this instances of this class were initialized at least 6 times. EDIT: Oops, I just read your EDIT! Yeah, that. |
|
@mingwandroid What happens if you remove the environment updates altogether? |
|
Ah, I see what the original is trying to do. The base |
|
I put up an alternative fix in #7963. |
|
It still isn't clear to me when not merging the original environment variables became a problem, the base class certainly doesn't do it. Perhaps that was due to using non-microsoft compilers. |
|
OK, I went with the alternate. Thanks @mingwandroid for initiating a fix for this problem. |
|
☔ The latest upstream changes (presumably #7963) made this pull request unmergeable. Please resolve the merge conflicts. |
Each time an MSVCCompiler is instantiated, os.environ['lib'] and
os.environ['include'] doubles. This leads to hitting the 32,768
character limit.