comparison setup.py @ 49395:747c4fc20886

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.

49394:5cf73de964e1

            f.write(out)


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"?>
    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
        <application>

        </application>
    </assembly>"""

    def initialize_options(self):
        build_ext.initialize_options(self)
        self.long_paths_support = False

    def build_extensions(self):
        if os.name != 'nt':
            return
        if isinstance(self.compiler, HackedMingw32CCompiler):

            macros=[('_UNICODE', None), ('UNICODE', None)],
        )
        self.compiler.link_executable(
            objects, self.hgtarget, libraries=[], output_dir=self.build_temp
        )
        if self.long_paths_support:
            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.

        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.
        """
        exefname = self.compiler.executable_filename(self.hgtarget)

        log.info("running mt.exe to update hg.exe's manifest in-place")
        # supplying both -manifest and -inputresource to mt.exe makes
        # it merge the embedded and supplied manifests in the -outputresource
        self.spawn(
            [
                'mt.exe',
                '-nologo',
                '-manifest',
                manfname,
                inputresource,
                outputresource,

49395:747c4fc20886

            f.write(out)


class buildhgexe(build_ext):
    description = 'compile hg.exe from mercurial/exewrapper.c'

    LONG_PATHS_MANIFEST = """
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
        <application>

        </application>
    </assembly>"""

    def initialize_options(self):
        build_ext.initialize_options(self)

    def build_extensions(self):
        if os.name != 'nt':
            return
        if isinstance(self.compiler, HackedMingw32CCompiler):

            macros=[('_UNICODE', None), ('UNICODE', None)],
        )
        self.compiler.link_executable(
            objects, self.hgtarget, libraries=[], output_dir=self.build_temp
        )

        self.addlongpathsmanifest()

    def addlongpathsmanifest(self):
        """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.
        """
        exefname = self.compiler.executable_filename(self.hgtarget)

        log.info("running mt.exe to update hg.exe's manifest in-place")
        # supplying both -manifest and -inputresource to mt.exe makes
        # it merge the embedded and supplied manifests in the -outputresource
        self.spawn(
            [
                self.compiler.mt,
                '-nologo',
                '-manifest',
                manfname,
                inputresource,
                outputresource,