[sql] Framework for allowing tests to handle errors.

sql/sql.gyp

 # Copyright (c) 2012 The Chromium Authors. All rights reserved.
 # Use of this source code is governed by a BSD-style license that can be
 # found in the LICENSE file.
 
 {
   'variables': {
     'chromium_code': 1,
   },
   'targets': [
     {
       'target_name': 'sql',
       'type': '<(component)',
       'dependencies': [
         '../base/base.gyp:base',
+        '../base/third_party/dynamic_annotations/dynamic_annotations.gyp:dynamic_annotations',

[Scott Hess - ex-Googler, 2013/06/13 20:41:03]

Having the scoper own the callback and pass a _pointer_ to it up to
Connection::SetErrorIgnorer() allows this line to go away.

         '../third_party/sqlite/sqlite.gyp:sqlite',
       ],
       'defines': [ 'SQL_IMPLEMENTATION' ],
       'sources': [
         'connection.cc',
         'connection.h',
         'error_delegate_util.cc',
         'error_delegate_util.h',
         'init_status.h',
         'meta_table.cc',
         'meta_table.h',
         'statement.cc',
         'statement.h',
         'transaction.cc',
         'transaction.h',
       ],
       # TODO(jschuh): crbug.com/167187 fix size_t to int truncations.
       'msvs_disabled_warnings': [4267, ],
     },
     {
+      'target_name': 'test_support_sql',
+      'type': 'static_library',
+      'dependencies': [
+        'sql',
+        '../base/base.gyp:test_support_base',

[Scott Hess - ex-Googler, 2013/06/13 20:41:03]

I don't understand gyp at all.  If I don't include this (or base.gyp:base), I
get a compile failure because scoped_error_ignorer.cc cannot find
sql/test/scoped_error_ignorer.h.  Possibly due to direct_dependent_settings
adding include_dirs '..' in target base?

test_support_sql doesn't actually use test_support_base, but does use base, so
I'm going to depend on that, even though AFAICT I only depend on base for the
implementation of something for sql, so that seems debatable as an IWYU.

[erikwright (departed), 2013/06/13 22:58:06]

You use base/basictypes.h and base/bind.h, so you do depend on base directly and
should declare that dependency.

To be formal you should probably have include_dirs explicitly list '..' here and
also put it in direct_dependent_settings.

[Scott Hess - ex-Googler, 2013/06/13 23:58:39]

I'm not sure I understand this.  base.gyp has:
      'direct_dependent_settings': {
        'include_dirs': [
          '..',
        ],
      },
on target 'base', not on 'test_support_base'.  Some other targets have:
      'include_dirs': [
        '..',
      ],
but not 'test_support_base' or 'base'.  So does this imply that those should be
on target 'sql' rather than 'test_support_sql'?

[erikwright (departed), 2013/06/17 17:42:29]

GYP is so complicated, and there is so much boilerplate, that I think lots of
targets do not really get it right but still work out in the end. So (1) your CL
will probably still work if it's not "perfect" and (2) you can't rely on what
you see elsewhere to tell you how it should be.

My comments here are based on my interpretation only, not on any rigorous
documentation or standard.

I think that every target should declare its own include_dirs to point to the
root from which its files should be included.

And I think that for targets A, B, and C (where C depends on B depends on A)
every target B should list, in export_dependent_settings, any targets A that
would be effective direct dependencies of targets C. That's the case if
including "public" headers from B will lead to the inclusion of headers from A.

The reasoning is that there could realistically be settings defined by target A
that are needed in order for C to properly interpret a.h.

"A" knows what those settings are, "B" knows that those settings need to be
propagated to its dependents, and "C" only knows that it depends on "B" and thus
relies on "B" to to the right thing.

+        '../testing/gtest.gyp:gtest',
+      ],
+      'export_dependent_settings': [
+        'sql',
+      ],

[Scott Hess - ex-Googler, 2013/06/13 20:41:03]

Do you know if this clause is necessary?  I just copied what test_support_base
does.  It doesn't seem necessary for the existing CL, but maybe it is necessary
for other code to depend on it?

[erikwright (departed), 2013/06/13 22:58:06]

The purpose of this is because your dependents depend on 'sql' (and 'base')
because, simply by including your header (scoped_error_ignorer.h) they are
including 'sql/..' and 'base/..'. So if there are DEFINEs, include_dirs, and
other options that they need because of those transitive dependencies
'export_dependent_settings' allows you to pass those things on to them.

So you should add 'base' here. But you don't need to add gtest.

[Scott Hess - ex-Googler, 2013/06/13 23:58:39]

Makes sense.  Does this imply that the 'sql' target should also have
'export_dependent_settings' for the 'base' dependency?  AFAICT, the 'sqlite'
dependency is not exposed in any headers.

[erikwright (departed), 2013/06/17 17:42:29]

I did a git grep and confirm that only base/ and sql/ are included from
sql/**.h. So, yes, I believe sql should export dependent_settings from 'base'.

+      'sources': [
+        'test/scoped_error_ignorer.cc',
+        'test/scoped_error_ignorer.h',
+      ],
+    },
+    {
       'target_name': 'sql_unittests',
       'type': '<(gtest_target_type)',
       'dependencies': [
         'sql',
+        'test_support_sql',
         '../base/base.gyp:test_support_base',
         '../testing/gtest.gyp:gtest',
       ],
       'sources': [
         'run_all_unittests.cc',
         'connection_unittest.cc',
         'sqlite_features_unittest.cc',
         'statement_unittest.cc',
         'transaction_unittest.cc',
       ],
@@ skipping 34 matching lines @@
           'variables': {
             'test_suite_name': 'sql_unittests',
             'input_shlib_path': '<(SHARED_LIB_DIR)/<(SHARED_LIB_PREFIX)sql_unittests<(SHARED_LIB_SUFFIX)',
           },
           'includes': [ '../build/apk_test.gypi' ],
         },
       ],
     }],
   ],
 }