setup: unconditionally enable the `long-paths-support` option on Windows
authorMatt Harbison <matt_harbison@yahoo.com>
Mon, 18 Jul 2022 17:19:56 -0400
changeset 49395 747c4fc20886
parent 49394 5cf73de964e1
child 49396 ece490b02a9b
setup: unconditionally enable the `long-paths-support` option on Windows I don't see anything talking about why this was experimental in the first place, but maybe it was concern about the level of python2 support for it. But now, both `python.exe` and the PyOxidizer build of `hg.exe` have a manifest that enables it, so leaving it off would mean some Mercurial installations could operate on a repo with long paths, and others couldn't. Note that only the wide character functions (XxxW) will have the length restriction lifted. Sadly, distutils applies `/MANIFEST:EMBED` to the linker in a way that can't easily be turned off, so we can't use `/MANIFESTFILE` with `extra_preargs` on `link_executable`. Fortunately, the compiler object provides a path to the `mt.exe` it found during initialization, because the previous incarnation seems to have assumed it is being run within an activated Visual Studio environment. That causes MSYS builds to fail, and probably would have broke the CI environment.
setup.py
--- a/setup.py	Mon Jul 18 17:00:59 2022 -0400
+++ b/setup.py	Mon Jul 18 17:19:56 2022 -0400
@@ -666,15 +666,6 @@
 
 class buildhgexe(build_ext):
     description = 'compile hg.exe from mercurial/exewrapper.c'
-    user_options = build_ext.user_options + [
-        (
-            'long-paths-support',
-            None,
-            'enable support for long paths on '
-            'Windows (off by default and '
-            'experimental)',
-        ),
-    ]
 
     LONG_PATHS_MANIFEST = """
     <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
@@ -689,7 +680,6 @@
 
     def initialize_options(self):
         build_ext.initialize_options(self)
-        self.long_paths_support = False
 
     def build_extensions(self):
         if os.name != 'nt':
@@ -774,22 +764,11 @@
         self.compiler.link_executable(
             objects, self.hgtarget, libraries=[], output_dir=self.build_temp
         )
-        if self.long_paths_support:
-            self.addlongpathsmanifest()
+
+        self.addlongpathsmanifest()
 
     def addlongpathsmanifest(self):
-        r"""Add manifest pieces so that hg.exe understands long paths
-
-        This is an EXPERIMENTAL feature, use with care.
-        To enable long paths support, one needs to do two things:
-        - build Mercurial with --long-paths-support option
-        - change HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\
-                 LongPathsEnabled to have value 1.
-
-        Please ignore 'warning 81010002: Unrecognized Element "longPathAware"';
-        it happens because Mercurial uses mt.exe circa 2008, which is not
-        yet aware of long paths support in the manifest (I think so at least).
-        This does not stop mt.exe from embedding/merging the XML properly.
+        """Add manifest pieces so that hg.exe understands long paths
 
         Why resource #1 should be used for .exe manifests? I don't know and
         wasn't able to find an explanation for mortals. But it seems to work.
@@ -807,7 +786,7 @@
         # it merge the embedded and supplied manifests in the -outputresource
         self.spawn(
             [
-                'mt.exe',
+                self.compiler.mt,
                 '-nologo',
                 '-manifest',
                 manfname,