Better code to determine the framework and helper app paths

Eliminate char/wchar_t conversions, probably-unsafe statics, and disk access
when determining the framework and helper app paths on the Mac.

BUG=24833
TEST=app still works, tests still pass

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=29034

[TVL, 2009-10-14 19:58:13]

lgtm

[Mark Mentovai, 2009-10-14 20:43:09]

For real this time

[TVL, 2009-10-14 21:09:15]

http://codereview.chromium.org/267102/diff/6001/7005
File chrome/chrome.gyp (right):

http://codereview.chromium.org/267102/diff/6001/7005#newcode492
Line 492: },
see base.gyp:linux_versioninfo, yes, it reached up into the chrome directory.  
I know i've seen complaints on that building too often in the past, so this
seems like something related that we should be careful about.

http://codereview.chromium.org/267102/diff/6001/7002
File chrome/common/chrome_paths_mac.mm (right):

http://codereview.chromium.org/267102/diff/6001/7002#newcode71
Line 71: NSBundle* app_bundle = [NSBundle mainBundle];
since the concern in here was threading,
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/Multith...
says NSBundle isn't really thread safe...

http://codereview.chromium.org/267102/diff/6001/7004
File chrome/tools/build/make_version_cc.py (right):

http://codereview.chromium.org/267102/diff/6001/7004#newcode23
Line 23: extern const char kChromeVersion[] = "%s";
why extern?

[Mark Mentovai, 2009-10-14 21:26:46]

http://codereview.chromium.org/267102/diff/6001/7005
File chrome/chrome.gyp (right):

http://codereview.chromium.org/267102/diff/6001/7005#newcode492
Line 492: },
TVL wrote:
> see base.gyp:linux_versioninfo, yes, it reached up into the chrome directory. 

> I know i've seen complaints on that building too often in the past, so this
> seems like something related that we should be careful about.

I think that the main problem with linux_versioninfo is that it embeds the SVN
revision.  That can change a lot more frequently than VERSION.

http://codereview.chromium.org/267102/diff/6001/7002
File chrome/common/chrome_paths_mac.mm (right):

http://codereview.chromium.org/267102/diff/6001/7002#newcode71
Line 71: NSBundle* app_bundle = [NSBundle mainBundle];
TVL wrote:
> since the concern in here was threading,

Good point.  If we care about this, we should fix base/base_paths_mac.mm too,
which implements FILE_EXE and FILE_MODULE in terms of [[NSBundle mainBundle]
executablePath].

I'm not positive that there's a fantastic way to fix this.  I guess we could use
_NSGetExecutablePath, but we'd need to absolutize it ourselves.

I'll file a p1 bug.

http://codereview.chromium.org/267102/diff/6001/7004
File chrome/tools/build/make_version_cc.py (right):

http://codereview.chromium.org/267102/diff/6001/7004#newcode23
Line 23: extern const char kChromeVersion[] = "%s";
TVL wrote:
> why extern?

I needed something extern in the file or ar would just throw the whole thing
out.  extern is actually correct for C++.

[TVL, 2009-10-14 21:40:08]

lgtm

[Mark Mentovai, 2009-10-14 21:51:06]

I wrote:
> http://codereview.chromium.org/267102/diff/6001/7002#newcode71
> Line 71: NSBundle* app_bundle =3D [NSBundle mainBundle];
> TVL wrote:
>>
>> since the concern in here was threading,
>
> Good point. =A0If we care about this, we should fix base/base_paths_mac.m=
m
> too, which implements FILE_EXE and FILE_MODULE in terms of [[NSBundle
> mainBundle] executablePath].
>
> I'm not positive that there's a fantastic way to fix this. =A0I guess we
> could use _NSGetExecutablePath, but we'd need to absolutize it
> ourselves.
>
> I'll file a p1 bug.

Bug 24842.

Mark