[FR] Use shortest path, rather than alphabetically first, for /IMPLIB

[JamesTheAwesomeDude]

What's the problem this feature will solve?

When compiling clib extensions on Windows, sometimes the path length limit is hit, which causes compilation to fail.

(This is, of course, not a bug in setuptools, but a bug in MSVC.)

Describe the solution you'd like

It would fix this in some cases, with I believe minimal breakage, if msvccompiler.py were changed from its current behavior of putting the output file in the same directory as the source file with the lexographically smallest path, to putting the output file in the same directory as the source file with the genuinely smallest path:

--- a/setuptools/_distutils/msvccompiler.py
+++ b/setuptools/_distutils/msvccompiler.py
@@ -555,4 +555,5 @@ class MSVCCompiler(CCompiler):
                 implib_file = os.path.join(
-                    os.path.dirname(objects[0]), self.library_filename(dll_name)
+                    os.path.dirname(min(objects, key=len)),
+                    self.library_filename(dll_name)
                 )
                 ld_args.append('/IMPLIB:' + implib_file)

Alternative Solutions

The current work-around is to require the building user to configure a short path for env TMPDIR. This is severely suboptimal while the error messages don't communicate this.

An alternative fix would be to revert the /IMPLIB injection code to its pre-06830ad behavior, changing it from sticking the extension next to the “first” source file— which means “first passed-in” in distutils < 3.9, but changed to “first alphabetically” in 2020 with distutils ≥ 3.9 —to its original behavior of putting it in the top-level build temp folder next to the other “compiler turds”.

--- a/setuptools/_distutils/msvccompiler.py
+++ b/setuptools/_distutils/msvccompiler.py
@@ -555,4 +555,4 @@ class MSVCCompiler(CCompiler):
                 implib_file = os.path.join(
-                    os.path.dirname(objects[0]), self.library_filename(dll_name)
+                    build_temp, self.library_filename(dll_name)
                 )
                 ld_args.append('/IMPLIB:' + implib_file)

While this would be an extremely clean fix, it's suboptimal because it would technically have marginally more breakage than the fix I'm requesting, because it's conceivable that someone's codebase relies on the /IMPLIB target neighboring some source file.

---

Another alternative fix would be to revert the changes in 95234bb and 3665ddc and simply respect the original passed-in order; this is suboptimal because it would break any workflows that rely on setuptools doing this sorting.

Another alternative fix would be if it were possible for the caller to optionally indicate which source file is the "primary" one that the output library should neighbor, or to opt out of having the source files re-ordered, which would almost completely eliminate the risk of breaking existing workflows; this is suboptimal because it would involve creating a new interface.

Another alternative fix would be to sort the paths by length in the first place; this is suboptimal because it might break workflows that rely on the current inclusion order.

Another alternative fix would be to wrap the current call to dirname() in a subsequent call to realpath(); this would fix it in my case (where the path is bloated by .. entries), but is suboptimal because it would not help it in the general case.

Additional context

https://discuss.python.org/t/inconsistently-getting-error-1104-while-building-a-clib-cffi-extension-on-windows/44077/5

Code of Conduct

• I agree to follow the PSF Code of Conduct