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

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark Hammond wrote:
> 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! :)

I think it could be as simple as having a known function to call with
given arguments.
So in bzr's setup.py you have

from tbzrlib import setup_config
setup_config.configure_for_setup(current_state...)

Which could probably be re-used in tbzr's setup.py (if it had one).

Similarly for qbzr and bzr-svn. Though I guess you do "setup.py install"
for those plugins, rather than how you do it for tbzr.

> 
>> +    # 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.
> 

It seems like something that we would *like* to have built
automatically, rather than having to run "setup.py build" in the tbzr
location, and then doing it again for bzr.

I suppose whatever mechanism will just be wrapped into the
"get-everything-built" script that I wrote anyway.



>>          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.
> 

K. I think I'd like to have that statement verbatim here. To explain the
difference.


>> 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.
> 

But only for the single .dll, right? Does that add any appreciable size?


>> 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
> 
> 

I think so.

John
=:->

PS> BB:tweak ish, though BB won't let me vote this far down in the thread.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklH+OsACgkQJdeBCYSNAAPjVACgmTC3/ArU7bWxBPlvAio0BPsr
IxwAoJ+lBeY090ISnlONdXIa3nEZPc/u
=Z2Mp
-----END PGP SIGNATURE-----