Make checkdeps --resolve-dotdot succeed.

Make checkdeps --resolve-dotdot succeed.

R=tsepez@chromium.org

Committed: https://pdfium.googlesource.com/pdfium/+/79f5a32175293620abe456554e10efb7c3f4e7c6

[Lei Zhang, 2015-11-04 10:07:45]

thestig@chromium.org changed reviewers:
+ tsepez@chromium.org

[Lei Zhang, 2015-11-04 10:07:45]

And then we can add a buildbot step to run this check.

[dsinclair, 2015-11-04 14:09:16]

dsinclair@chromium.org changed reviewers:
+ dsinclair@chromium.org

[dsinclair, 2015-11-04 14:09:17]

https://codereview.chromium.org/1419373005/diff/1/public/DEPS
File public/DEPS (right):

https://codereview.chromium.org/1419373005/diff/1/public/DEPS#newcode3
public/DEPS:3: '-third_party',
Should this also be -core -fpdfsdk (and -xfa on the branch)?

[Lei Zhang, 2015-11-04 18:14:25]

https://codereview.chromium.org/1419373005/diff/1/public/DEPS
File public/DEPS (right):

https://codereview.chromium.org/1419373005/diff/1/public/DEPS#newcode3
public/DEPS:3: '-third_party',
On 2015/11/04 14:09:16, dsinclair wrote:
> Should this also be -core -fpdfsdk (and -xfa on the branch)?

It's belt and suspenders, but sure.

[Lei Zhang, 2015-11-04 18:17:58]

See patch set 2.

[Tom Sepez, 2015-11-04 18:50:56]

https://codereview.chromium.org/1419373005/diff/20001/DEPS
File DEPS (right):

https://codereview.chromium.org/1419373005/diff/20001/DEPS#newcode37
DEPS:37: # Basic stuff that everyone can use.
Nope.  core/ can't include public.  All API access has to go through fpdfsdk/,
sometimes (pointlessly) translating to equivalent types at the core/ boundary.

https://codereview.chromium.org/1419373005/diff/20001/core/include/fpdfapi/fp...
File core/include/fpdfapi/fpdf_render.h (right):

https://codereview.chromium.org/1419373005/diff/20001/core/include/fpdfapi/fp...
core/include/fpdfapi/fpdf_render.h:10: #include
"../../../public/fpdf_progressive.h"
Hence, this really is illegal.

https://codereview.chromium.org/1419373005/diff/20001/fpdfsdk/DEPS
File fpdfsdk/DEPS (left):

https://codereview.chromium.org/1419373005/diff/20001/fpdfsdk/DEPS#oldcode4
fpdfsdk/DEPS:4: '+public',
fpdfsdk does get to depend on public.

https://codereview.chromium.org/1419373005/diff/20001/public/DEPS
File public/DEPS (right):

https://codereview.chromium.org/1419373005/diff/20001/public/DEPS#newcode2
public/DEPS:2: # public/ needs to be basically standealone. Explicitly disallow
everything.
nit: s/basically//.

https://codereview.chromium.org/1419373005/diff/20001/samples/DEPS
File samples/DEPS (left):

https://codereview.chromium.org/1419373005/diff/20001/samples/DEPS#oldcode3
samples/DEPS:3: '+public',
Obviously, Samples can call public.

https://codereview.chromium.org/1419373005/diff/20001/testing/DEPS
File testing/DEPS (left):

https://codereview.chromium.org/1419373005/diff/20001/testing/DEPS#oldcode4
testing/DEPS:4: '+public',
and again.

https://codereview.chromium.org/1419373005/diff/20001/third_party/DEPS
File third_party/DEPS (right):

https://codereview.chromium.org/1419373005/diff/20001/third_party/DEPS#newcode3
third_party/DEPS:3: '+core/include/fxcrt',
can we list the few files, fx_memory.h and fx_whatever.h explicitly so that it
doesn't grow?  How about on a per-product basis?  I'd hate to see a pure
libmumble get fx-ified down the road.

[Lei Zhang, 2015-11-04 19:30:54]

https://codereview.chromium.org/1419373005/diff/20001/DEPS
File DEPS (right):

https://codereview.chromium.org/1419373005/diff/20001/DEPS#newcode37
DEPS:37: # Basic stuff that everyone can use.
On 2015/11/04 18:50:56, Tom Sepez wrote:
> Nope.  core/ can't include public.  All API access has to go through fpdfsdk/,
> sometimes (pointlessly) translating to equivalent types at the core/ boundary.

But there's code that violates this. Want me to fix them?

[Lei Zhang, 2015-11-04 19:31:18]

https://codereview.chromium.org/1419373005/diff/20001/core/include/fpdfapi/fp...
File core/include/fpdfapi/fpdf_render.h (right):

https://codereview.chromium.org/1419373005/diff/20001/core/include/fpdfapi/fp...
core/include/fpdfapi/fpdf_render.h:10: #include
"../../../public/fpdf_progressive.h"
On 2015/11/04 18:50:56, Tom Sepez wrote:
> Hence, this really is illegal.

Umm, ya, like this one.

[Tom Sepez, 2015-11-04 19:41:48]

> But there's code that violates this. Want me to fix them?
That would be swell.  Also, when you get around to DEPS for core/ maybe add a
comment about "no public/"?

[Lei Zhang, 2015-11-04 21:49:12]

All done. See incremental steps in patch set 3 and 4.

[Tom Sepez, 2015-11-04 22:00:13]

lgtm

[Lei Zhang, 2015-11-04 22:16:31]

Committed patchset #5 (id:80001) manually as
79f5a32175293620abe456554e10efb7c3f4e7c6 (presubmit successful).

[Tom Sepez, 2015-11-04 22:23:02]

On 2015/11/04 22:16:31, Lei Zhang wrote:
> Committed patchset #5 (id:80001) manually as
> 79f5a32175293620abe456554e10efb7c3f4e7c6 (presubmit successful).

When you merge this to XFA, I should mention that fpdfsdk -> xfa -> core is the
strict layering.

[Lei Zhang, 2015-11-04 22:24:26]

On 2015/11/04 22:23:02, Tom Sepez wrote:
> On 2015/11/04 22:16:31, Lei Zhang wrote:
> > Committed patchset #5 (id:80001) manually as
> > 79f5a32175293620abe456554e10efb7c3f4e7c6 (presubmit successful).
> 
> When you merge this to XFA, I should mention that fpdfsdk -> xfa -> core is
the
> strict layering.

Thanks. It's going to be a fun merge...