Avoid rebuilding remoting host every time gyp runs

Avoid rebuilding remoting host every time gyp runs

Previously CLSID for COM classes used in chromoting host on windows were
random, generated every time gyp runs. As result the targets that depend
on it had to be rebuilt even when there are no code changes. Changed
remoting.gyp to generate stable CLSID as a hash of the current version
number.

BUG=332679
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=249218

[Jamie, 2014-02-05 18:53:58]

lgtm with one suggestion.

https://codereview.chromium.org/146623004/diff/1/remoting/remoting.gyp
File remoting/remoting.gyp (right):

https://codereview.chromium.org/146623004/diff/1/remoting/remoting.gyp#newcode64
remoting/remoting.gyp:64: # current version string to make sure that the newly
installed COM
How will this impact dev builds on a machine? I've lost many hours debugging
code because it turns out the version that was running was not the version I was
editing. It feels like this might increase the risk of that. Unfortunately, I
think that's fundamentally at odds with the thing we're trying to fix in this
CL, so I don't think there's a lot we can do; I just wanted to raise it as a
concern in case you have any suggestions.

https://codereview.chromium.org/146623004/diff/1/remoting/remoting.gyp#newcode72
remoting/remoting.gyp:72: '<!(python -c "import uuid; print
uuid.uuid5(uuid.UUID(\'6a7699f0-ee43-43e7-aa30-a6738f9bd470\'),
\'<(version_full)\')")',
I was originally concerned about duplicating these uuids, but I don't think it's
necessary for them to be the same as the corresponding interface ids, correct?
Maybe just use two random uuids here and update the comment so that we don't
have to worry about it in the future.

[Sergey Ulanov, 2014-02-05 19:47:16]

https://codereview.chromium.org/146623004/diff/1/remoting/remoting.gyp
File remoting/remoting.gyp (right):

https://codereview.chromium.org/146623004/diff/1/remoting/remoting.gyp#newcode64
remoting/remoting.gyp:64: # current version string to make sure that the newly
installed COM
On 2014/02/05 18:53:58, Jamie wrote:
> How will this impact dev builds on a machine? I've lost many hours debugging
> code because it turns out the version that was running was not the version I
was
> editing. It feels like this might increase the risk of that. Unfortunately, I
> think that's fundamentally at odds with the thing we're trying to fix in this
> CL, so I don't think there's a lot we can do; I just wanted to raise it as a
> concern in case you have any suggestions.

I think potentially the IDs can be generated randomly as a separate build step. 
Problem is that the build target that generates IDs would need to depend on all 
code compiled into the host to make sure IDs are updated when code changes, but 
even then it wouldn't catch all cases. 

IMO proper solution is to stop using COM. FWIW we won't need COM for daemon
controller once NPAPI plugin is removed and I hope we can refactor
RDPDesktopSession to make it work without COM. So all COM dependencies can be
removed in the future, and then CLSID generation won't be a problem.

https://codereview.chromium.org/146623004/diff/1/remoting/remoting.gyp#newcode72
remoting/remoting.gyp:72: '<!(python -c "import uuid; print
uuid.uuid5(uuid.UUID(\'6a7699f0-ee43-43e7-aa30-a6738f9bd470\'),
\'<(version_full)\')")',
On 2014/02/05 18:53:58, Jamie wrote:
> I was originally concerned about duplicating these uuids, but I don't think
it's
> necessary for them to be the same as the corresponding interface ids, correct?
> Maybe just use two random uuids here and update the comment so that we don't
> have to worry about it in the future.

Correct. I've updated the comments to make it clear that the GUIDs don't have to
match the interfaces. Kept the actual values.

[Sergey Ulanov, 2014-02-05 19:47:56]

The CQ bit was checked by sergeyu@chromium.org

[commit-bot: I haz the power, 2014-02-05 19:59:32]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/sergeyu@chromium.org/146623004/80001

[commit-bot: I haz the power, 2014-02-06 02:07:21]

Change committed as 249218