Depend only on "real" jsoncpp repository, not chromium's wrapper of it

Depend only on "real" jsoncpp repository, not chromium's wrapper of it

[epoger, 2013-01-10 16:38:17]

Based on discussion in https://code.google.com/p/skia/source/detail?r=7115

This works when I do a "gclient sync" within my working checkout... it remains
to be seen whether it would work for clean checkouts.  (But I am optimistic)

The main question, I think, is whether we actually need any of the Chromium
wrapper stuff... as far as I know, we don't.

https://codereview.appspot.com/7063059/diff/1/DEPS
File DEPS (right):

https://codereview.appspot.com/7063059/diff/1/DEPS#newcode1
DEPS:1: use_relative_paths = True
Not shown in the codereview is this change to the SVN externals:

Property changes on:
/usr/local/google/home/epoger/src/skia/blue/trunk/third_party/externals
___________________________________________________________________
Modified: svn:externals
   - http://angleproject.googlecode.com/svn/trunk@1268 angle
http://cityhash.googlecode.com/svn/trunk@11 cityhash
http://gyp.googlecode.com/svn/trunk@1509 gyp
http://src.chromium.org/svn/trunk/src/third_party/libjpeg@125399 libjpeg
http://src.chromium.org/svn/trunk/src/third_party/jsoncpp@125399 jsoncpp
http://jsoncpp.svn.sourceforge.net/svnroot/jsoncpp/trunk/jsoncpp/include@248
jsoncpp/source/include
http://jsoncpp.svn.sourceforge.net/svnroot/jsoncpp/trunk/jsoncpp/src/lib_json...
jsoncpp/source/src/lib_json

   + http://angleproject.googlecode.com/svn/trunk@1268 angle
http://cityhash.googlecode.com/svn/trunk@11 cityhash
http://gyp.googlecode.com/svn/trunk@1509 gyp
http://src.chromium.org/svn/trunk/src/third_party/libjpeg@125399 libjpeg
http://jsoncpp.svn.sourceforge.net/svnroot/jsoncpp/trunk/jsoncpp@248 jsoncpp

[bungeman, 2013-01-10 17:01:36]

This DEPS change and props change lgtm, but I defer to Derek as to the substance
of the change, as he's the one who actually wants to use jasoncpp.

[epoger, 2013-01-10 17:07:45]

On 2013/01/10 17:01:36, bungeman wrote:
> This DEPS change and props change lgtm, but I defer to Derek as to the
substance
> of the change, as he's the one who actually wants to use jasoncpp.

Makes sense; I'll wait to get Derek's opinion.

(For the record, gm uses jsoncpp now... and the gm self-test proves that our
import of jsoncpp still works with this change.)

[DerekS, 2013-01-10 18:30:23]

If I remember correctly, I pulled some from Chromium as their copy had security
fixes and if we wanted to put this code into action in chromium and not just our
tools I didn't want to run into compiler errors.

If trying to avoid potential compiler errors is more trouble than the problem
that this is addressing then I'm fine with removing it.

[DerekS, 2013-01-10 18:30:25]

If I remember correctly, I pulled some from Chromium as their copy had security
fixes and if we wanted to put this code into action in chromium and not just our
tools I didn't want to run into compiler errors.

If trying to avoid potential compiler errors is more trouble than the problem
that this is addressing then I'm fine with removing it.

[epoger, 2013-01-11 21:03:44]

On 2013/01/10 18:30:25, DerekS wrote:
> If I remember correctly, I pulled some from Chromium as their copy had
security
> fixes and if we wanted to put this code into action in chromium and not just
our
> tools I didn't want to run into compiler errors.

In that case, it sounds like we should probably keep using Chromium's overrides.
 Closing in favor of https://codereview.appspot.com/7098047/ ('Separate our
jsoncpp dependency from Chromium's jsoncpp overrides.')