# HG changeset patch
# User Matt Harbison <matt_harbison@yahoo.com>
# Date 1658179196 14400
# Node ID 747c4fc20886a867e1ff7c6a1d05327537a5421d
# Parent  5cf73de964e193966976acb1093b3bef9086b16b
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.

diff -r 5cf73de964e1 -r 747c4fc20886 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,