Developer installation, gyp version

adblockplus.gyp

Index: adblockplus.gyp
===================================================================
--- a/adblockplus.gyp
+++ b/adblockplus.gyp
@@ -9,9 +9,82 @@
       'src/shared/Communication.cpp',
       'src/shared/Dictionary.cpp',
       'src/shared/Utils.cpp',
-    ]
+    ],
+    
+    # Architecture Detections

[Felix Dahlke, 2013/07/02 08:00:46]

This describes something that's happening in dev_install.cmd, right? I'd want to
move this documentation there then.

[Eric, 2013/07/02 12:58:06]

It's happening in both the install and uninstall command files. I've moved as
much of the logic as possible into the 'gyp' file, where we can make it common
and catch errors as early as possible.

+    # =======================
+    # We must make an effort to locate the correct executable to manipulate the registry,
+    #   because Windows automatically remaps "reg.exe" to a 32-bit version when invoked from a 32-bit program.
+    # There are _five_ different architectures relevant to this detection,
+    #   all of which come in 32-bit and 64-bit versions.
+    # 1. The architecture of the processor itself.
+    # 2. The architecture of the version of Windows running.
+    # 3. The architecture of the 'python' executable that runs 'gyp'.
+    # 4. The architecture of the executable running the build, which will we either MSBuild or Visual Studio.
+    # 5. The architecture of the build target.
+    # Unfortunately, we cannot know the architecture of the build executable at compile time,
+    #   so regardless of the architecture of python, we have a certain amount of build-time detection to do.
+    #
+    # The easy cases are 1 and 2.
+    # If Windows is 32-bit, then it doesn't matter what the processor is, all the executables are also 32-bit 
+    #   and only 32-bit registrations can be supported.
+    # We represent this value as the variable 'platform_arch'.
+    # We use it below to compile out the registration project for the case of 32-bit platform and 64-bit target.
+    # The detection we're using for this is outlined here: http://support.microsoft.com/kb/556009
+    # It requires querying a particular registry key that indicates the architecture of the OS.
+    # After that it's just a bunch of cmd.exe hacks to coerce the search result to one of two strings.
+    
+    'platform_arch': '<!(cmd /c reg query HKLM\\HARDWARE\\DESCRIPTION\\System\\CentralProcessor\\0 -v "Platform ID" | find "0x20" & if errorlevel 1 (echo x64) else echo ia32)'
+    
+    # Case 3 is relevant if only as a cautionary warning that it should be ignored.
+    # It's possible to detect the architecture of the python executable, but it doesn't do any good
+    #   because there's no relationship between it and that of the build executable.
+    # Case 4 would be called 'build_arch' here if it were possible to know it in advance, but we can't.
+    # Case 5 is available as gyp variable 'target_arch'.
+    
+    # For 32-bit Windows, we have only one case; everything is 32-bit.
+    # For 64-bit Windows, we have four cases depending on the architectures of the spawning process and which view of the registry to write to.
+    # platform  spawn  executable                  registry   comment
+    # ========  =====  ==========                  ========   =======
+    #    32       32   %WINDIR%\System32\reg.exe      32      Native
+    #    64       32   %WINDIR%\System32\reg.exe      32      Path name is remapped, even if fully specified
+    #    64       64   %WINDIR%\SysWOW64\reg.exe      32      'SysWOW64' visible to both 32-bit and 64-bit processes                
+    #    64       32   %WINDIR%\sysnative\reg.exe     64      Virtual directory 'sysnative' only visible in this combination
+    #    64       64   %WINDIR%\System32\reg.exe      64      Native
+    # Under 64-bit Windows, 32-bit keys appear under a "Wow6432Node" key when seen natively, that is, with a 64-bit binary,
+    #   but without the modifier when seen under WoW64, that is, with a 32-bit binary.
+    # In order to keep the syntax consistent, we want 32-bit binaries for 32-bit targets
+    #   and 64-bit binaries for 64-bit targets.
+    # We need to detect the architecture of the (batch file) process at run time, but given that and the platform architecture,
+    #   we can select the right "reg.exe" to run.
+    # This allows us to keep the syntax of the registration statements identical except for the path to "reg.exe".
+    # See 'dev_install.cmd' for the implementation. 
   },
-
+  'conditions': [
+    [ 'platform_arch=="ia32"', {
+      'variables': {
+        'reg32': 'system32', 
+        'reg64': 'system32'     # Something needed so that the .cmd file has sufficient arguments 
+      } 
+    } ],
+    [ 'platform_arch=="x64"', {
+      'conditions': [
+        [ 'target_arch=="ia32"', {
+          'variables': {
+            'reg32': 'system32', 
+            'reg64': 'SysWOW64' 
+          } 
+        } ],
+        [ 'target_arch=="x64"', {
+          'variables': {
+            'reg32': 'sysnative',
+            'reg64': 'system32'
+          } 
+        } ],
+      ],
+    } ]
+  ],
+    
   'target_defaults': {
     'conditions': [
       [
@@ -149,6 +222,43 @@
       },
     },
   },
+  
+  {
+    'target_name': 'Developer Install',
+    'type': 'none',
+    'dependencies': [
+      'AdblockPlus'
+    ],
+    'actions': [ {
+      'action_name': 'Install',
+      'message': 'Performing a developer installation',
+      'inputs': [],
+      'outputs': [
+        # This file is never written, meaning the action always runs.

[Oleksandr, 2013/07/02 08:16:17]

Can you please elaborate on this part? I don't quite get it - if it is never
written - why is it here?

[Eric, 2013/07/02 12:58:06]

MSBuild is essentially a glorified Makefile, special-purposed for Microsoft
tools. When there's a target that doesn't exist, the builder runs the action
that builds it. (It does not, however, ensure that it's there afterwards.)
Having a non-written target ensure that the custom action always runs.

It's possible that it might be able to be omitted, but that's one more MSBuild
thing to research, to make sure it won't fail for whatever reason in the future.

+        '<(PRODUCT_DIR)/timestamp.txt'
+      ],
+      'action': [ 
+        '..\\..\\dev_install.cmd "$(OutDir)Adblockplus.dll" "$(ProjectDir)" <(reg32) <(reg64)', 
+      ],
+    } ],
+  },
+
+  {
+    'target_name': 'Developer Uninstall',
+    'type': 'none',
+    'actions': [ {
+      'action_name': 'Uninstall',
+      'message': 'Removing any developer installation',
+      'inputs': [],
+      'outputs': [
+        # This file is never written, meaning the action always runs.
+        '<(PRODUCT_DIR)/timestamp.txt'
+      ],
+      'action': [ 
+        '..\\..\\dev_uninstall.cmd <(reg32) <(reg64)', 

[Felix Dahlke, 2013/07/02 08:00:46]

So this means that I cannot just run dev_uninstall.cmd from the command line
without arguments? How can I run it?

I'm wondering if it wouldn't be better to just pass the architecture in to the
scripts, and they determine the directories from that.

[Eric, 2013/07/02 12:58:06]

It would be possible to pass in the architecture itself. That would mean adding
more conditional checks to the .cmd files (install and uninstall) and
duplicating the code.

To run it, just build the "Developer Uninstall" project in the generated
solution. Uninstall is on a per-architecture basis. The only time a developer
would need to uninstall the developer keys, though, is to use the regularly
installed (with MSI) version.

+      ],
+    } ],
+  },
 
   {
     'target_name': 'tests',