[MERGE] Support for tbzr c++ implemented shell extension

[Mark Hammond]

Thanks John,

> As a friendly reminder, we really should get the tbzr stuff split out.
> (Not at this time, though.)

Yeah - I'm happy to discuss exactly what this means any time you are! :)

> 
> +    # The C++ implemented shell extensions.
> +    dist_dir = os.path.join(tbzr_root, "shellext", "cpp",
> "tbzrshellext",
> +                            "build", "dist")
> +    data_files.append(('', [os.path.join(dist_dir,
> 'tbzrshellext_x86.dll')]))
> +    data_files.append(('', [os.path.join(dist_dir,
> 'tbzrshellext_x64.dll')]))
> +
> 
> 
> ^- It seems pretty strange to hard-code the path to the file in this
> way, but I'm guessing that is what it takes right now.

We are hard-coding the sub-directory where the C++ build process creates the DLL.  This location should be stable unless someone changes the Visual Studio project files.  I didn't mention in the patch that running "setup.py build" in tbzr will create these .DLLs.

> 
>          if root == 'bzrlib/plugins':
>              plugins = set(dirs)
> +            # py2exe may find references to part of the plugin (eg,
> the
> tests)
> +            # so we tell py2exe to leave the plugins out of the .zip
> file
> +            excludes.extend(["bzrlib.plugins." + d for d in dirs])
> 
> 
> ^- I don't understand this change. Isn't the whole point that we want
> to
> bring in plugins? Is it just that we bring them all in manually, rather
> than having py2exe do it for us?

We ship plugins as normal files on the file-system - however, the build process can cause *some* of these plugin files to end up in library.zip.  Thus, I saw (eg) "plugins/svn/test" in library.zip, and then saw import errors related to that as the rest of the svn plugin wasn't.  The above change avoids any part of the plugins ending up in library.zip file.

> 
> How does that work with automatically bringing in the various
> dependency
> libraries that plugins need? Is it again that we just list them all
> manually?

The dependencies of the plugins work as normal, and do still end up in the .zip file.

> 
> 
> +        # Ditto for TORTOISE_OVERLAYS_MSI_X64, pointing at *-x64.msi.
> +        for needed in ('TORTOISE_OVERLAYS_MSI_WIN32',
> +                       'TORTOISE_OVERLAYS_MSI_X64'):
> 
> ^- Do I understand correctly that now the installer bundles 32-bit
> *and*
> 64-bit versions of everything?

No: there is a 32 and 64bit version of the shell extension DLL only.  Everything else remains 32 bits.  However, even on a 64bit install, you must still install the 32bit shell extension so 32bit programs can use the shell extension capabilities.

So, on a 32bit OS, everything is installed other than the single 64bit DLL.  On a 64bit OS, *everything* is installed (excepting the tortoise overlays)

> Would it be reasonable to split out a 32-bit installer versus a 64-bit
> installer?

See above - I think a single installer is the simplest and easiest, and it detects a 32bit OS and doesn't attempt to install the 64bit shell extension.  The downside though is that the 32bit installer is bigger than it needs to be.

> How does it work with the python version we are building. It seems like
> we would always be using 32-bit python, rather than both 32 and 64 bit.
> But perhaps the standard "python*.msi" file includes both, and py2exe
> knows how to package both at the same time.

See above - the C++ shell extension has given us the luxury of being able to ignore 64bit Python versions for now.

> 
> ...
> 
> +        DeleteFileNowOrLater(ExpandConstant('{app}\tbzr.dll'));
> +        DeleteFileNowOrLater(ExpandConstant('{app}\tbzrtest.exe'));
> +        DeleteFileNowOrLater(ExpandConstant('{app}\tbzr_tracer.exe'));
> 
> ^- This is nice to have. Does this properly handle "you really do need
> to reboot" (a file was in use) versus "you may need to reboot" (no
> files
> were in use, and everything went fine, but I don't have any idea
> whether
> that was true or not, so I always prompt you to reboot)?

The DeleteFileNowOrLater() will *attempt* to remove a the file now, but if it fails, will schedule the file to be removed at next reboot.  It will *not* in itself cause a reboot request at the end of the installer - the user will not be aware a reboot is required to finally remove these files.

However, in practical terms, if the user has not previously uninstalled, then tbzr.dll will be in-use, and that in-turn will cause other files in our installation to be in-use (eg, the .pyd files) - and *that* fact will cause Inno's normal process to prompt for a reboot to finally install those .pyd files.   So in practical terms, I expect that each time DeleteFileNowOrLater needs to schedule the removal for reboot time, a reboot will be required.  Indeed, it was quite difficult for me to test that part of the installer - ie, to have eep.dll be in use but *not* any other files needed at install time.

I hope that clarifies most things...

Cheers,

Mark