Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
16664005:
[sql] Framework for allowing tests to handle errors. (Closed)
|
Created:
7 years, 6 months ago by Scott Hess - ex-Googler Modified:
7 years, 6 months ago Reviewers:
erikwright (departed) CC:
chromium-reviews Base URL:
svn://svn.chromium.org/chrome/trunk/src Visibility:
Public. |
Description[sql] Framework for allowing tests to handle errors.
sql/ throws FATAL whenever it sees inappropriate calls, which makes
production code to handle errors hard to test. ScopedErrorIgnorer
provides a way for tests to signal that specific errors are expected
and will be handled.
As a first pass, code up some additional tests for some Raze() edge
cases, and modify things to pass those tests.
BUG=159490
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=207096
Patch Set 1 #Patch Set 2 : tie-poh #Patch Set 3 : Call ShouldIgnoreError() in all modes. #
Total comments: 8
Patch Set 4 : Refactor along lines of comment #4. #
Total comments: 30
Patch Set 5 : Erik's comments, plus lazy instance for global. #
Total comments: 9
Patch Set 6 : Convert to using a callback pointer to get rid of lazy instance. #Patch Set 7 : Erik's suggested gyp changes. #
Total comments: 2
Patch Set 8 : final gyp cleanup. #
Messages
Total messages: 18 (0 generated)
Found an old CL on a random laptop and cleaned it up...
The recent chance was necessary because otherwise the tests failed in release mode because in debug mode: DLOG_IF(FATAL, ShouldIgnoreError()) <<... ShouldIgnoreError() would never be called. Another option would be to put a check for DLOG_IS_ON(FATAL) in CheckIgnoredErrors(), but that felt poor to me since it would mean the tests weren't really testing things on release builds.
https://codereview.chromium.org/16664005/diff/13001/sql/connection.cc File sql/connection.cc (right): https://codereview.chromium.org/16664005/diff/13001/sql/connection.cc#newcode338 sql/connection.cc:338: // SQLITE_NOTADB can happen if page 1 exists but is not formatted Can/should this block be a separate CL? https://codereview.chromium.org/16664005/diff/13001/sql/connection.cc#newcode843 sql/connection.cc:843: CHECK(checked_); This should probably be ADD_FAILURE instead of CHECK. As it stands now, it will cause a crash, obscuring actual test failures. If you use ADD_FAILURE it will just add an additional failure that can be ignored. That also seems to imply that ScopedErrorIgnorer should probably be only defined in test code, and you should provide some way (maybe a pure-virtual or something) to be able to access its state from production code but carry on without needing its implementation if there doesn't happen to be an active instance of it. https://codereview.chromium.org/16664005/diff/13001/sql/connection.cc#newcode874 sql/connection.cc:874: // Check extended code. It seems like either line 874 or 864 is wrong? https://codereview.chromium.org/16664005/diff/13001/sql/connection.h File sql/connection.h (right): https://codereview.chromium.org/16664005/diff/13001/sql/connection.h#newcode548 sql/connection.h:548: // Specific errors must be ignores, and all ignored errors must be Grammar problems to the point that I don't know what this line means. https://codereview.chromium.org/16664005/diff/13001/sql/connection.h#newcode556 sql/connection.h:556: class SQL_EXPORT ScopedErrorIgnorer { I'd have to scan sql/ to see what the local convention is, but I'm a big fan of one class per file and would prefer to see this moved into sql/scoped_error_ignorer.h, for example.
No new changes up, but please consider my echo of what I think you asked for (at "OK, so...") in case I mis-understood you. https://codereview.chromium.org/16664005/diff/13001/sql/connection.cc File sql/connection.cc (right): https://codereview.chromium.org/16664005/diff/13001/sql/connection.cc#newcode338 sql/connection.cc:338: // SQLITE_NOTADB can happen if page 1 exists but is not formatted On 2013/06/11 18:54:19, erikwright wrote: > Can/should this block be a separate CL? It's in here so that the example tests can pass. But I can put together a more targeted test and get this out of here. https://codereview.chromium.org/16664005/diff/13001/sql/connection.cc#newcode843 sql/connection.cc:843: CHECK(checked_); On 2013/06/11 18:54:19, erikwright wrote: > This should probably be ADD_FAILURE instead of CHECK. > > As it stands now, it will cause a crash, obscuring actual test failures. If you > use ADD_FAILURE it will just add an additional failure that can be ignored. > > That also seems to imply that ScopedErrorIgnorer should probably be only defined > in test code, and you should provide some way (maybe a pure-virtual or > something) to be able to access its state from production code but carry on > without needing its implementation if there doesn't happen to be an active > instance of it. Basically I hate all this :-). OK, so would it make sense to have a class like sql::Connection::ErrorIgnorer which is pure virtual with something like ShouldIgnoreError(). Then ScopedErrorIgnorer is in a separate file, and links into the sql::Connection global via a private setter and friend access. To limit it to tests, ScopedErrorIgnorer can be in a test_support_sql target for purposes of exposing itself to tests which want to use it (like base.gyp:test_support_base). Does that make sense? https://codereview.chromium.org/16664005/diff/13001/sql/connection.cc#newcode874 sql/connection.cc:874: // Check extended code. On 2013/06/11 18:54:19, erikwright wrote: > It seems like either line 874 or 864 is wrong? Doh, this one is checking the non-extended code.
OK, new changes along the lines of comment #4. I also tried a version using an abstract base class. It felt like six of one versus half a dozen of the other. The callback version was less wordy, so I went with that. It is also probably a tiny bit less performant, but the goal is for SQLite errors to never happen in production, so I don't think that should be a concern.
On 2013/06/13 00:22:08, shess wrote: > I also tried a version using an abstract base class. It felt like six of one > versus half a dozen of the other. The callback version was less wordy, so I > went with that. It is also probably a tiny bit less performant, but the goal is > for SQLite errors to never happen in production, so I don't think that should be > a concern. Come to think of it, I could easily be argued around WRT thread safety. This code is inherently un-thread-safe. In production the hook will never be set. In testing it should only be set from the main thread, but other threads could be running database operations. Unfortunately, I cannot really think of a way around that in a general case, but the actual access to the hook could be improved. [Dammit. This is probably a static initializer, isn't it? I'll poke at the specifics of Connection::current_ignorer_cb_, but that change should be pretty localized.]
https://codereview.chromium.org/16664005/diff/23001/sql/connection.cc File sql/connection.cc (right): https://codereview.chromium.org/16664005/diff/23001/sql/connection.cc#newcode464 sql/connection.cc:464: // in production if the schema is corrupted. Fix up the capitalization/grammar here. https://codereview.chromium.org/16664005/diff/23001/sql/sql.gyp File sql/sql.gyp (right): https://codereview.chromium.org/16664005/diff/23001/sql/sql.gyp#newcode37 sql/sql.gyp:37: 'defines': [ 'SQL_IMPLEMENTATION' ], I think this define should be removed. It is only correct when the target is being linked into sql.dll (this code is not). https://codereview.chromium.org/16664005/diff/23001/sql/sql.gyp#newcode55 sql/sql.gyp:55: 'test_support_sql', In the spirit of IWYU I think you should not rely on the transitive dependency on sql but rather include it explicitly. https://codereview.chromium.org/16664005/diff/23001/sql/test/scoped_error_ign... File sql/test/scoped_error_ignorer.cc (right): https://codereview.chromium.org/16664005/diff/23001/sql/test/scoped_error_ign... sql/test/scoped_error_ignorer.cc:1: // Copyright (c) 2012 The Chromium Authors. All rights reserved. 2013 https://codereview.chromium.org/16664005/diff/23001/sql/test/scoped_error_ign... sql/test/scoped_error_ignorer.cc:8: #include "base/logging.h" not required. https://codereview.chromium.org/16664005/diff/23001/sql/test/scoped_error_ign... sql/test/scoped_error_ignorer.cc:15: Connection::SetErrorIgnorer( include connection.h in this .cc file https://codereview.chromium.org/16664005/diff/23001/sql/test/scoped_error_ign... sql/test/scoped_error_ignorer.cc:16: base::Bind(&sql::ScopedErrorIgnorer::ShouldIgnore, no sql namespace required here. https://codereview.chromium.org/16664005/diff/23001/sql/test/scoped_error_ign... sql/test/scoped_error_ignorer.cc:22: ADD_FAILURE() << " Test must call CheckIgnoredErrors()"; This can also be EXPECT_FALSE(checked) << "..."; But if you prefer this syntax I don't mind. https://codereview.chromium.org/16664005/diff/23001/sql/test/scoped_error_ign... sql/test/scoped_error_ignorer.cc:29: ADD_FAILURE() << " Error " << err << " is already ignored"; same here. https://codereview.chromium.org/16664005/diff/23001/sql/test/scoped_error_ign... sql/test/scoped_error_ignorer.cc:55: ADD_FAILURE() << " Unexpected SQLite error " << err; Personally I wonder why we would DCHECK on unexpected errors normally but only ADD_FAILURE if an unexpected error occurs while we are expecting other errors. https://codereview.chromium.org/16664005/diff/23001/sql/test/scoped_error_ign... File sql/test/scoped_error_ignorer.h (right): https://codereview.chromium.org/16664005/diff/23001/sql/test/scoped_error_ign... sql/test/scoped_error_ignorer.h:8: #include "sql/connection.h" not required. https://codereview.chromium.org/16664005/diff/23001/sql/test/scoped_error_ign... sql/test/scoped_error_ignorer.h:26: class SQL_EXPORT ScopedErrorIgnorer { SQL_EXPORT is inappropriate. This target is a static library in all configurations. https://codereview.chromium.org/16664005/diff/23001/sql/test/scoped_error_ign... sql/test/scoped_error_ignorer.h:50: std::set<int> ignore_errors_; IWYU <set> https://codereview.chromium.org/16664005/diff/23001/sql/test/scoped_error_ign... sql/test/scoped_error_ignorer.h:55: DISALLOW_COPY_AND_ASSIGN(ScopedErrorIgnorer); IWYU base/basictypes.h
https://codereview.chromium.org/16664005/diff/23001/sql/test/scoped_error_ign... File sql/test/scoped_error_ignorer.h (right): https://codereview.chromium.org/16664005/diff/23001/sql/test/scoped_error_ign... sql/test/scoped_error_ignorer.h:38: // TODO(shess): How to handle ASSERT_X() cases which cause early I guess this TODO is now closed?
Thank you for the useful comments, this is feeling stronger to me. I also prototyped a version using a pointer for the callback global, and manual new/delete. It felt a little icky. Another option would be for the scoper to store the callback locally and pass in a pointer to it for the global. I'm still thinking on that, but I need to leave for the evening. https://codereview.chromium.org/16664005/diff/23001/sql/connection.cc File sql/connection.cc (right): https://codereview.chromium.org/16664005/diff/23001/sql/connection.cc#newcode464 sql/connection.cc:464: // in production if the schema is corrupted. On 2013/06/13 01:26:24, erikwright wrote: > Fix up the capitalization/grammar here. Done. A snippet got lost somewhere in editing. https://codereview.chromium.org/16664005/diff/23001/sql/sql.gyp File sql/sql.gyp (right): https://codereview.chromium.org/16664005/diff/23001/sql/sql.gyp#newcode37 sql/sql.gyp:37: 'defines': [ 'SQL_IMPLEMENTATION' ], On 2013/06/13 01:26:24, erikwright wrote: > I think this define should be removed. It is only correct when the target is > being linked into sql.dll (this code is not). Done. https://codereview.chromium.org/16664005/diff/23001/sql/sql.gyp#newcode55 sql/sql.gyp:55: 'test_support_sql', On 2013/06/13 01:26:24, erikwright wrote: > In the spirit of IWYU I think you should not rely on the transitive dependency > on sql but rather include it explicitly. Done. https://codereview.chromium.org/16664005/diff/23001/sql/test/scoped_error_ign... File sql/test/scoped_error_ignorer.cc (right): https://codereview.chromium.org/16664005/diff/23001/sql/test/scoped_error_ign... sql/test/scoped_error_ignorer.cc:1: // Copyright (c) 2012 The Chromium Authors. All rights reserved. On 2013/06/13 01:26:24, erikwright wrote: > 2013 Done. https://codereview.chromium.org/16664005/diff/23001/sql/test/scoped_error_ign... sql/test/scoped_error_ignorer.cc:8: #include "base/logging.h" On 2013/06/13 01:26:24, erikwright wrote: > not required. Done. https://codereview.chromium.org/16664005/diff/23001/sql/test/scoped_error_ign... sql/test/scoped_error_ignorer.cc:15: Connection::SetErrorIgnorer( On 2013/06/13 01:26:24, erikwright wrote: > include connection.h in this .cc file Done. https://codereview.chromium.org/16664005/diff/23001/sql/test/scoped_error_ign... sql/test/scoped_error_ignorer.cc:16: base::Bind(&sql::ScopedErrorIgnorer::ShouldIgnore, On 2013/06/13 01:26:24, erikwright wrote: > no sql namespace required here. Done. https://codereview.chromium.org/16664005/diff/23001/sql/test/scoped_error_ign... sql/test/scoped_error_ignorer.cc:22: ADD_FAILURE() << " Test must call CheckIgnoredErrors()"; On 2013/06/13 01:26:24, erikwright wrote: > This can also be EXPECT_FALSE(checked) << "..."; > > But if you prefer this syntax I don't mind. Done. https://codereview.chromium.org/16664005/diff/23001/sql/test/scoped_error_ign... sql/test/scoped_error_ignorer.cc:29: ADD_FAILURE() << " Error " << err << " is already ignored"; On 2013/06/13 01:26:24, erikwright wrote: > same here. Done. https://codereview.chromium.org/16664005/diff/23001/sql/test/scoped_error_ign... sql/test/scoped_error_ignorer.cc:55: ADD_FAILURE() << " Unexpected SQLite error " << err; On 2013/06/13 01:26:24, erikwright wrote: > Personally I wonder why we would DCHECK on unexpected errors normally but only > ADD_FAILURE if an unexpected error occurs while we are expecting other errors. I am wondering that myself. I can see the utility of piling on ADD_FAILURE() cases in a gtest context, rather than crashing. But I still want to see it fatal when people aren't in a gtest context because so much of this code handles failure by halfway working. AFAICT, the only way to get the ADD_FAILURE() version is to opt in using something like this. https://codereview.chromium.org/16664005/diff/23001/sql/test/scoped_error_ign... File sql/test/scoped_error_ignorer.h (right): https://codereview.chromium.org/16664005/diff/23001/sql/test/scoped_error_ign... sql/test/scoped_error_ignorer.h:8: #include "sql/connection.h" On 2013/06/13 01:26:24, erikwright wrote: > not required. Ah, lack of an abstract base class means it can go away. https://codereview.chromium.org/16664005/diff/23001/sql/test/scoped_error_ign... sql/test/scoped_error_ignorer.h:26: class SQL_EXPORT ScopedErrorIgnorer { On 2013/06/13 01:26:24, erikwright wrote: > SQL_EXPORT is inappropriate. This target is a static library in all > configurations. OK. I'm well into cargo-cult land, here. https://codereview.chromium.org/16664005/diff/23001/sql/test/scoped_error_ign... sql/test/scoped_error_ignorer.h:38: // TODO(shess): How to handle ASSERT_X() cases which cause early On 2013/06/13 01:27:57, erikwright wrote: > I guess this TODO is now closed? This relates to code like: sql::ScopedErrorIgnorer ignore_errors; ignore_errors.IgnoreError(SQLITE_CONSTRAINT); ASSERT_FALSE(db().Execute("INSERT INTO foo (id) VALUES (12)")); ASSERT_TRUE(ignore_errors.CheckIgnoredErrors()); If the INSERT statement _succeeds_, then CheckIgnoredErrors() is never called. Am I being too pedantic? I can't (offhand) think of any way where the ADD_FAILURE() in the destructor is going to be called which will in itself cause a test failure. AFAICT, it can only happen if the test already failed, in which case it will just add a little noise. OK, you've convinced me. https://codereview.chromium.org/16664005/diff/23001/sql/test/scoped_error_ign... sql/test/scoped_error_ignorer.h:50: std::set<int> ignore_errors_; On 2013/06/13 01:26:24, erikwright wrote: > IWYU <set> Done. https://codereview.chromium.org/16664005/diff/23001/sql/test/scoped_error_ign... sql/test/scoped_error_ignorer.h:55: DISALLOW_COPY_AND_ASSIGN(ScopedErrorIgnorer); On 2013/06/13 01:26:24, erikwright wrote: > IWYU base/basictypes.h Done.
OK. I tried the version with the callback owned by the scoper, and the global being a pointer to that, and while it looks a little sketchy, I think it's probably worth it to get away from the lazy-instance stuff. I think the ownership concerns are the same either way, since the lazy-instance callback referred to the scoper anyhow. PTAL. I'm going to go find a candidate test outside of sql/ for converting to see whether the export_dependent_settings thing matters. https://chromiumcodereview.appspot.com/16664005/diff/39001/sql/sql.gyp File sql/sql.gyp (right): https://chromiumcodereview.appspot.com/16664005/diff/39001/sql/sql.gyp#newcode15 sql/sql.gyp:15: '../base/third_party/dynamic_annotations/dynamic_annotations.gyp:dynamic_annotations', Having the scoper own the callback and pass a _pointer_ to it up to Connection::SetErrorIgnorer() allows this line to go away. https://chromiumcodereview.appspot.com/16664005/diff/39001/sql/sql.gyp#newcode40 sql/sql.gyp:40: '../base/base.gyp:test_support_base', 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. https://chromiumcodereview.appspot.com/16664005/diff/39001/sql/sql.gyp#newcode45 sql/sql.gyp:45: ], 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?
LG. I'll verify your final gyp changes. https://chromiumcodereview.appspot.com/16664005/diff/39001/sql/sql.gyp File sql/sql.gyp (right): https://chromiumcodereview.appspot.com/16664005/diff/39001/sql/sql.gyp#newcode40 sql/sql.gyp:40: '../base/base.gyp:test_support_base', On 2013/06/13 20:41:03, shess wrote: > 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. 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. https://chromiumcodereview.appspot.com/16664005/diff/39001/sql/sql.gyp#newcode45 sql/sql.gyp:45: ], On 2013/06/13 20:41:03, shess wrote: > 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? 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.
Added your suggestions, with some interpretation. I think. I did go out and use this in some other code, and it seems to work fine. https://chromiumcodereview.appspot.com/16664005/diff/39001/sql/sql.gyp File sql/sql.gyp (right): https://chromiumcodereview.appspot.com/16664005/diff/39001/sql/sql.gyp#newcode40 sql/sql.gyp:40: '../base/base.gyp:test_support_base', On 2013/06/13 22:58:06, erikwright wrote: > To be formal you should probably have include_dirs explicitly list '..' here and > also put it in direct_dependent_settings. 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'? https://chromiumcodereview.appspot.com/16664005/diff/39001/sql/sql.gyp#newcode45 sql/sql.gyp:45: ], On 2013/06/13 22:58:06, erikwright wrote: > On 2013/06/13 20:41:03, shess wrote: > > 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? > > 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. 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.
LGTM. https://chromiumcodereview.appspot.com/16664005/diff/39001/sql/sql.gyp File sql/sql.gyp (right): https://chromiumcodereview.appspot.com/16664005/diff/39001/sql/sql.gyp#newcode40 sql/sql.gyp:40: '../base/base.gyp:test_support_base', On 2013/06/13 23:58:39, shess wrote: > On 2013/06/13 22:58:06, erikwright wrote: > > To be formal you should probably have include_dirs explicitly list '..' here > and > > also put it in direct_dependent_settings. > > 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'? 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. https://chromiumcodereview.appspot.com/16664005/diff/39001/sql/sql.gyp#newcode45 sql/sql.gyp:45: ], On 2013/06/13 23:58:39, shess wrote: > On 2013/06/13 22:58:06, erikwright wrote: > > On 2013/06/13 20:41:03, shess wrote: > > > 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? > > > > 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. > > 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. 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'. https://chromiumcodereview.appspot.com/16664005/diff/57001/sql/sql.gyp File sql/sql.gyp (right): https://chromiumcodereview.appspot.com/16664005/diff/57001/sql/sql.gyp#newcode53 sql/sql.gyp:53: 'export_dependent_settings': [ nit, add 'include_dirs' -> '..' here too.
OK. I think I'm almost understanding things, more's the pity. * 'dependencies' - IWYU * 'export_dependent_settings' - dependencies you expose to your dependents. * top-level 'include_dirs' to indicate the root for your includes. * 'direct_dependent_settings' to pass out things callers need to make your exposed stuff work right. And since everyone wants base/, which has 'include_dirs' = '..' already, half or all of that can be omitted and nobody will notice. https://codereview.chromium.org/16664005/diff/57001/sql/sql.gyp File sql/sql.gyp (right): https://codereview.chromium.org/16664005/diff/57001/sql/sql.gyp#newcode53 sql/sql.gyp:53: 'export_dependent_settings': [ On 2013/06/17 17:42:30, erikwright wrote: > nit, add 'include_dirs' -> '..' here too. I am taking this to mean an include_dirs stanza for the overall target, not for this piece of the target. Like in the sql target.
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/[email protected]/16664005/69001
Retried try job too often on win_rel for step(s) browser_tests http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_rel&nu...
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/[email protected]/16664005/69001
Message was sent while issue was closed.
Change committed as 207096 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
