Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(411)

Issue 2830013: chrome_common.gypi: added dependency on bzip2.gyp, needed by following files: (Closed)

Created:
10 years, 6 months ago by Paweł Hajdan Jr.
Modified:
9 years, 7 months ago
Reviewers:
ananta, TVL, agl, Evan Martin
CC:
chromium-reviews
Visibility:
Public.

Description

chrome_common.gypi: added dependency on bzip2.gyp, needed by following files: bzip2_unittest.cc metrics_helpers.cc The issue got detected while preparing the package for Gentoo Linux. We remove the third party libraries completely, and without that dep the mentioned files try to use the bundled headers instead of system-provided ones. TEST=none BUG=none Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=50254

Patch Set 1 #

Unified diffs Side-by-side diffs Delta from patch set Stats (+1 line, -0 lines) Patch
M chrome/chrome_common.gypi View 1 chunk +1 line, -0 lines 0 comments Download

Messages

Total messages: 6 (0 generated)
Paweł Hajdan Jr.
10 years, 6 months ago (2010-06-18 07:22:38 UTC) #1
ananta
LGTM
10 years, 6 months ago (2010-06-18 13:01:49 UTC) #2
agl
LGTM
10 years, 6 months ago (2010-06-18 14:22:14 UTC) #3
TVL
drive by: if those targets need bzip2, why don't they depend on it? ie-if you ...
10 years, 6 months ago (2010-06-18 14:26:56 UTC) #4
Paweł Hajdan Jr.
On 2010/06/18 14:26:56, TVL wrote: > drive by: > > if those targets need bzip2, ...
10 years, 6 months ago (2010-06-18 17:22:36 UTC) #5
Evan Martin
10 years, 6 months ago (2010-06-21 15:29:41 UTC) #6
On 2010/06/18 17:22:36, Paweł Hajdan Jr. wrote:
> Now why wasn't it detected before? Because the third party bzip2 headers are
> normally still there (physically). If one builds with system bzip2, but
> something accidentally uses the bundled headers, it's hard to notice unless
some
> evil header mismatch causes trouble.

I wonder how many situations this problem comes up in.  :(

I wonder if there's a way to make it fail to compile rather than get mixed
headers?  I guess we have the source root in the -I flags and the includes look
like "third_party/whatever/", so moving the unused third_party bits out of the
way like you have done might be the best we can do...

I guess you could use the -H flag to gcc and grep the output for mentions of the
bad directories, but that would probably be kind of annoying to set up.

Powered by Google App Engine
This is Rietveld 408576698