Linux: revive a mysteriously disabled test and add tests for the GNOME Keyring native backend.

Linux: revive a mysteriously disabled test and add tests for the GNOME Keyring native backend.
In order to make the GNOME Keyring API mockable, I've substituted evil preprocessor macros with a slightly less evil scoping trick, and used it even when linking directly.
I'm not sure when password_store_x_unittest fell out of the gyp file, but it hasn't been compiled for some time apparently so it required a bit of cleanup to make it compile.
I also did a little unrelated cleanup in the gyp files and fixed typos in password_store_default_unittest.
BUG=none
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=93093

[Evan Martin, 2011-07-18 15:30:59]

Awesome!

http://codereview.chromium.org/7396013/diff/7001/build/linux/system.gyp
File build/linux/system.gyp (right):

http://codereview.chromium.org/7396013/diff/7001/build/linux/system.gyp#newco...
build/linux/system.gyp:382: 'target_name': 'gnome-keyring-direct',
I think we normally use underscores for these names.  Not sure though.

Can you put a comment above this describing what this target does?  (Seems like
it's a dependency of anything that wants to link to gnome-keyring directly or
something...)

http://codereview.chromium.org/7396013/diff/7001/build/linux/system.gyp#newco...
build/linux/system.gyp:383: 'type': 'settings',
It turns out this type actually doesn't exist in gyp, but it succeeds due to a
bug in the make generator!  I have been trying to remove it.  Can you use 'none'
instead?

http://codereview.chromium.org/7396013/diff/7001/chrome/browser/password_mana...
File chrome/browser/password_manager/native_backend_gnome_x.h (right):

http://codereview.chromium.org/7396013/diff/7001/chrome/browser/password_mana...
chrome/browser/password_manager/native_backend_gnome_x.h:61: static const
FunctionInfo functions[];
I'm surprised this is legal -- you'd think the array is inline so the compiler
needs to know the size of the array in the header.  Maybe we're saved because
it's static?  No worries.

http://codereview.chromium.org/7396013/diff/7001/chrome/browser/password_mana...
chrome/browser/password_manager/native_backend_gnome_x.h:67: public
GnomeKeyringLoader {
This is weird.  The class is all statics, right?  So it's just for namespacing? 
Why do we need this?

http://codereview.chromium.org/7396013/diff/7001/chrome/chrome_tests.gypi
File chrome/chrome_tests.gypi (right):

http://codereview.chromium.org/7396013/diff/7001/chrome/chrome_tests.gypi#new...
chrome/chrome_tests.gypi:2091: 'sources!': [
IIRC you need to use sources/ in some weird circumstances because it has
different precedence than sources!

Be careful that this works correctly...

[Mike Mammarella, 2011-07-19 00:20:35]

http://codereview.chromium.org/7396013/diff/7001/build/linux/system.gyp
File build/linux/system.gyp (right):

http://codereview.chromium.org/7396013/diff/7001/build/linux/system.gyp#newco...
build/linux/system.gyp:382: 'target_name': 'gnome-keyring-direct',
On 2011/07/18 15:31:00, Evan Martin wrote:
> I think we normally use underscores for these names.  Not sure though.
> 
> Can you put a comment above this describing what this target does?  (Seems
like
> it's a dependency of anything that wants to link to gnome-keyring directly or
> something...)

Done.

http://codereview.chromium.org/7396013/diff/7001/build/linux/system.gyp#newco...
build/linux/system.gyp:383: 'type': 'settings',
On 2011/07/18 15:31:00, Evan Martin wrote:
> It turns out this type actually doesn't exist in gyp, but it succeeds due to a
> bug in the make generator!  I have been trying to remove it.  Can you use
'none'
> instead?

So, I changed this, and then the unit tests stopped linking with unknown symbol
errors for the symbols I'm using from libgnomekeyring. Changing it back and
forth toggled the errors, so apparently this does have some effect and 'none' is
not the same.

http://codereview.chromium.org/7396013/diff/7001/chrome/browser/password_mana...
File chrome/browser/password_manager/native_backend_gnome_x.h (right):

http://codereview.chromium.org/7396013/diff/7001/chrome/browser/password_mana...
chrome/browser/password_manager/native_backend_gnome_x.h:61: static const
FunctionInfo functions[];
On 2011/07/18 15:31:00, Evan Martin wrote:
> I'm surprised this is legal -- you'd think the array is inline so the compiler
> needs to know the size of the array in the header.  Maybe we're saved because
> it's static?  No worries.

Yes, static is what saves us. Would you be as surprised if I'd written static
const char kSomeConstString[]; ?

http://codereview.chromium.org/7396013/diff/7001/chrome/browser/password_mana...
chrome/browser/password_manager/native_backend_gnome_x.h:67: public
GnomeKeyringLoader {
On 2011/07/18 15:31:00, Evan Martin wrote:
> This is weird.  The class is all statics, right?  So it's just for
namespacing? 
> Why do we need this?

The comment above explains this somewhat; is it not sufficiently clear?
Basically this is a name resolution ordering trick to get rid of the
preprocessor macros #define gnome_keyring_foo wrap_gnome_keyring_foo

http://codereview.chromium.org/7396013/diff/7001/chrome/chrome_tests.gypi
File chrome/chrome_tests.gypi (right):

http://codereview.chromium.org/7396013/diff/7001/chrome/chrome_tests.gypi#new...
chrome/chrome_tests.gypi:2091: 'sources!': [
On 2011/07/18 15:31:00, Evan Martin wrote:
> IIRC you need to use sources/ in some weird circumstances because it has
> different precedence than sources!
> 
> Be careful that this works correctly...

Hmm. I just figured this was somebody copy pasting something else, and not
knowing about the sources! feature. I did run it through the trybots, but the
original reason could be very subtle if it was intentional for some precedence
reasons. I guess I'll change it back.

[Evan Martin, 2011-07-19 17:37:59]

LGTM