MacViews: Fix compile regression after SmartLock error bubble in r313408

MacViews: Fix compile regression after SmartLock error bubble in r313408

toolkit-views builds on mac are getting:
Undefined symbols for architecture x86_64:
   ShowProximityAuthErrorBubble

To fix, move proximity_auth_error_bubble.cc to mac_sources. This works
because the symbol is only referenced on platforms with extensions,
which are toolkit_views platforms + mac.

After proximity_auth_error_bubble_view.cc moves in
chrome_browser_ui.gypi from chrome_browser_ui_views_non_mac_sources to
chrome_browser_ui_views_sources then proximity_auth_error_bubble.cc can
be deleted.

BUG=399191
TBR=sky@chromium.org

Committed: https://crrev.com/d07e66d8c4f32281bc94653eefa992b8e35580fc
Cr-Commit-Position: refs/heads/master@{#313888}

[tapted, 2015-01-29 05:58:21]

tapted@chromium.org changed reviewers:
+ isherman@chromium.org

[tapted, 2015-01-29 06:03:11]

Hi Ilya, please take a look.

(also any plans to add c/b/ui/[views/]proximity_auth/OWNERS :) ?

[Ilya Sherman, 2015-01-29 20:03:41]

I'd prefer to fix this at a GYP level.  If we're building Views code on Mac,
then let's just include the correct symbol there.

On 2015/01/29 06:03:11, tapted wrote:
> Hi Ilya, please take a look.
> 
> (also any plans to add c/b/ui/[views/]proximity_auth/OWNERS :) ?

Hmm, I suppose that's a good idea :)

[tapted, 2015-01-29 21:22:20]

On 2015/01/29 20:03:41, Ilya Sherman wrote:
> I'd prefer to fix this at a GYP level.  If we're building Views code on Mac,
> then let's just include the correct symbol there.

I've put up an alternative + updated CL description. PTAL.

Note toolkit_views is probably going to flip soon on Mac. However, the browser
will remain Cocoa until we try porting things in stages and test them all.
Compiling the views code on mac would count as "releasing" some views UI on Mac
before it's ready, since the symbol is referenced in extensions code rather than
views-only browser code. chrome_browser_ui_views_non_mac_sources will eventually
be mostly empty, but putting too much there will explode the binary and we're
not ready for that when the flag flips.

[Ilya Sherman, 2015-01-30 03:16:57]

Hmm, I think your second solution is likely to cause problems on other
platforms, where the symbol might be missing entirely.  I'm wary of any solution
that tries to address the issue by filtering based on platform, rather than by
whether or not the views toolkit is used.

After thinking about it some more, I think my preferred solution would be to
return to your first approach, but to use a different macro than OS_MACOSX. 
This would be a new macro, that is somehow specific to MacViews.  It would then
be easy to find all instances of the macro during a later cleanup pass, which is
the main property that's missing when just using the OS_MACOSX macro directly,
or when tweaking the gyp files in platform-specific ways.  WDYT?

[tapted, 2015-01-30 04:38:19]

On 2015/01/30 03:16:57, Ilya Sherman wrote:
> Hmm, I think your second solution is likely to cause problems on other
> platforms, where the symbol might be missing entirely.  I'm wary of any
solution
> that tries to address the issue by filtering based on platform, rather than by
> whether or not the views toolkit is used.
> 
> After thinking about it some more, I think my preferred solution would be to
> return to your first approach, but to use a different macro than OS_MACOSX. 
> This would be a new macro, that is somehow specific to MacViews.  It would
then
> be easy to find all instances of the macro during a later cleanup pass, which
is
> the main property that's missing when just using the OS_MACOSX macro directly,
> or when tweaking the gyp files in platform-specific ways.  WDYT?

OK - I think I have the answer :). PTAL.

We need to introduce views code gradually -- a single #define won't help with
that. (i.e. each piece needs to first be compiled in, put behind a
chrome://flag, sent to QA, made default, then unused code deleted. Any #define
we add would require everything to happen at once). But the end goal is aura
(which _does_ have to happen at once, but we can only think about that once
views draws all the UI).

And I'm already using checks like `#if defined(OS_MACOSX) && !defined(USE_AURA)`
for things like touch events, which aren't ready for desktop-mac but will need
to set off alarm bells before things are wound up.

[Ilya Sherman, 2015-01-30 05:21:19]

Alright, this approach seems more palatable to me -- thanks.  LGTM.

[tapted, 2015-01-30 09:02:22]

tapted@chromium.org changed reviewers:
+ sky@chromium.org

[tapted, 2015-01-30 09:03:37]

+sky TBR for c/b/ui owners - just an ifdef tweak

[tapted, 2015-01-30 09:03:57]

The CQ bit was checked by tapted@chromium.org

[commit-bot: I haz the power, 2015-01-30 09:04:34]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/887563003/40001

[commit-bot: I haz the power, 2015-01-30 09:28:47]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2015-01-30 09:29:56]

Patchset 3 (id:??) landed as
https://crrev.com/d07e66d8c4f32281bc94653eefa992b8e35580fc
Cr-Commit-Position: refs/heads/master@{#313888}