Change DEPS hooks paths to include 'pdfium/'.

Change DEPS hooks paths to include 'pdfium/'.

This will break existing checkouts based on the instructions provided.

Instead of having a single pdfium directory, checkouts will now compromise of:
("repo" can be named anything)

repo/.gclient
repo/pdfium/.git
repo/pdfium/others...

To convert an existing checkout, do something like:

mkdir repo
mv pdfium repo
rm repo/pdfium/.gclient_entries # will be regenerated, with a warning
mv repo/pdfium/.gclient repo
edit repo/.gclient and change "name: '.'" to "name: 'pdfium'"

Instructions for getting a new checkout are in README.md in this CL.

R=thestig@chromium.org, tsepez@chromium.org, thakis@chromium.org

Committed: https://pdfium.googlesource.com/pdfium/+/d0b794a102d1f37131c8f56c27f4a5fc9234a879

[Oliver Chang, 2015-10-19 23:41:57]

it doesn't look like there is a clean way to get the buildbots to checkout
'pdfium' on its own instead of 'pdfium/pdfium', so I'm uploading this patch for
discussion. 

This is needed so that buildbots can do "runhooks".

[Oliver Chang, 2015-10-19 23:42:50]

Description was changed from

==========
Change DEPS hooks paths to include 'pdfium/'.

This will break existing checkouts where .gclient is inside the pdfium
dir.

R=thestig@chromium.org,tsepez@chromium.org,thakis@chromium.org
==========

to

==========
Change DEPS hooks paths to include 'pdfium/'.

This will break existing checkouts where .gclient is inside the pdfium
dir, but needed so that buildbots can do runhooks.

R=thestig@chromium.org,tsepez@chromium.org,thakis@chromium.org
==========

[Tom Sepez, 2015-10-19 23:46:31]

Ok by me.

https://codereview.chromium.org/1406383003/diff/1/README.md
File README.md (right):

https://codereview.chromium.org/1406383003/diff/1/README.md#newcode14
README.md:14: mkdir pdfium
We might want to change this name to something like 'repo' or indicate that it
can be anything now.

https://codereview.chromium.org/1406383003/diff/1/README.md#newcode18
README.md:18: ```
You'll need to add a cd pdfium here.

[Lei Zhang, 2015-10-19 23:47:59]

Can we ask infra folks to see if there's a way to get the bots to checkout code
like the developers? I think we've gotten most developers away from
pdfium/pdfium and onto just pdfium, and it's a hassled to make everyone change
their setup again.

Personally, I had it as pdfium/pdfium before, so I don't really care.

[Oliver Chang, 2015-10-19 23:50:15]

https://codereview.chromium.org/1406383003/diff/1/README.md
File README.md (right):

https://codereview.chromium.org/1406383003/diff/1/README.md#newcode14
README.md:14: mkdir pdfium
On 2015/10/19 23:46:31, Tom Sepez wrote:
> We might want to change this name to something like 'repo' or indicate that it
> can be anything now.

Done.

https://codereview.chromium.org/1406383003/diff/1/README.md#newcode18
README.md:18: ```
On 2015/10/19 23:46:31, Tom Sepez wrote:
> You'll need to add a cd pdfium here.

Done.

[Oliver Chang, 2015-10-19 23:50:48]

On 2015/10/19 23:47:59, Lei Zhang wrote:
> Can we ask infra folks to see if there's a way to get the bots to checkout
code
> like the developers? I think we've gotten most developers away from
> pdfium/pdfium and onto just pdfium, and it's a hassled to make everyone change
> their setup again.
> 
> Personally, I had it as pdfium/pdfium before, so I don't really care.

I'll start a thread with some infra folks.

[Lei Zhang, 2015-10-20 00:00:09]

Nico: There are dozens of us! Dozens!

Basically we need to decide whether to go with pdfium or pdfium/pdfium and stop
seesawing back and forth.

[Lei Zhang, 2015-10-20 00:04:45]

>Another consideration is that _all other projects_ put their .gclient a level
up from where the "main" checkout is. Having special one-off cases for projects
is a real pain from infra, as I know from experience. If there's really dozens
(plural) that might be justifiable, but <= 10 people just getting with the
program is probably preferable :-) 

Sure. Can we take this to the pdfium mailing list and just settle it once and
for all? I really don't care either way. I just want consensus and no more
seesawing.

[dsinclair, 2015-10-20 13:25:03]

On 2015/10/20 00:04:45, Lei Zhang wrote:
> >Another consideration is that _all other projects_ put their .gclient a level
> up from where the "main" checkout is. Having special one-off cases for
projects
> is a real pain from infra, as I know from experience. If there's really dozens
> (plural) that might be justifiable, but <= 10 people just getting with the
> program is probably preferable :-) 
> 
> Sure. Can we take this to the pdfium mailing list and just settle it once and
> for all? I really don't care either way. I just want consensus and no more
> seesawing.


Why not pdfium/src?

One other benefit of this is we can pretty easily create a fetch recipe for
pdfium if this (whichever version is picked) is done. Then the checkout command
just becomes:

fetch pdfium

which is kinda nice.

[Nico, 2015-10-20 13:30:53]

On 2015/10/20 13:25:03, dsinclair wrote:
> On 2015/10/20 00:04:45, Lei Zhang wrote:
> > >Another consideration is that _all other projects_ put their .gclient a
level
> > up from where the "main" checkout is. Having special one-off cases for
> projects
> > is a real pain from infra, as I know from experience. If there's really
dozens
> > (plural) that might be justifiable, but <= 10 people just getting with the
> > program is probably preferable :-) 
> > 
> > Sure. Can we take this to the pdfium mailing list and just settle it once
and
> > for all? I really don't care either way. I just want consensus and no more
> > seesawing.
> 
> 
> Why not pdfium/src?
> 
> One other benefit of this is we can pretty easily create a fetch recipe for
> pdfium if this (whichever version is picked) is done. Then the checkout
command
> just becomes:
> 
> fetch pdfium
> 
> which is kinda nice.

Cause the inner name is usually the name of the repo, and the repo is called
pdfium (renaming it would give us third_party/src instead of t_p/pdfium without
further special casing)

[Lei Zhang, 2015-10-20 16:46:57]

On 2015/10/20 13:30:53, Nico (afk Tue Oct 20) wrote:
> Cause the inner name is usually the name of the repo, and the repo is called
> pdfium (renaming it would give us third_party/src instead of t_p/pdfium
without
> further special casing)

We could have third_party/pdfium be in the Chromium repo, and check the PDFium
code into third_party/pdfium/src

[Lei Zhang, 2015-10-20 16:58:51]

On 2015/10/20 16:46:57, Lei Zhang wrote:
> On 2015/10/20 13:30:53, Nico (afk Tue Oct 20) wrote:
> > Cause the inner name is usually the name of the repo, and the repo is called
> > pdfium (renaming it would give us third_party/src instead of t_p/pdfium
> without
> > further special casing)
> 
> We could have third_party/pdfium be in the Chromium repo, and check the PDFium
> code into third_party/pdfium/src

> That'd work, yes. It's usually the convention we use if we have out of tree
build files (e.g. T_p/yasm has gyp/gn build files in that folder and the deps'd
in upstream source in a src subfolder), but doing this with upstream build files
and having T_p/pdfium completely empty except for a src subfolder seems fine.

> Probably best if you (thestig) just decide something and spare us the bike
shed :-)

If I play decider, I'd just say move back to pdfium/pdfium for pdfium developers
and leave it alone for Chromium. If someone does not like pdfium/pdfium, they
can checkout code wherever they like and put in a pdfium symlink. Assuming they
are on a real OS. ;)

[Tom Sepez, 2015-10-20 17:12:33]

I'm OK with thestig@ as decider.

[Tom Sepez, 2015-10-20 17:14:04]

https://codereview.chromium.org/1406383003/diff/20001/README.md
File README.md (right):

https://codereview.chromium.org/1406383003/diff/20001/README.md#newcode14
README.md:14: mkdir repo
Need a note that says that the name of this top-level directory does not matter,
but we will use repo for our examples.

[Oliver Chang, 2015-10-20 17:19:49]

https://codereview.chromium.org/1406383003/diff/20001/README.md
File README.md (right):

https://codereview.chromium.org/1406383003/diff/20001/README.md#newcode14
README.md:14: mkdir repo
On 2015/10/20 17:14:04, Tom Sepez wrote:
> Need a note that says that the name of this top-level directory does not
matter,
> but we will use repo for our examples.

Done.

[Tom Sepez, 2015-10-20 17:25:36]

LGTM % nit, but get Lei to approve as well.

https://codereview.chromium.org/1406383003/diff/40001/README.md
File README.md (right):

https://codereview.chromium.org/1406383003/diff/40001/README.md#newcode14
README.md:14: # The name of the top-level directory does not matter. In our
examples, we use
nit: I'd move this before the ```, and lose the #. Also, it dawns on me that we
might like to mention that a given top-level directory can only handle one
gclient configuration, so make sure its distinct from any other directory to
which you have already glient config'd.

[Oliver Chang, 2015-10-20 17:35:45]

https://codereview.chromium.org/1406383003/diff/40001/README.md
File README.md (right):

https://codereview.chromium.org/1406383003/diff/40001/README.md#newcode14
README.md:14: # The name of the top-level directory does not matter. In our
examples, we use
On 2015/10/20 17:25:36, Tom Sepez wrote:
> nit: I'd move this before the ```, and lose the #. Also, it dawns on me that
we
> might like to mention that a given top-level directory can only handle one
> gclient configuration, so make sure its distinct from any other directory to
> which you have already glient config'd.

Done, but I suck at putting together sentences, so let me know if you want this
reworded.

[Tom Sepez, 2015-10-20 17:36:53]

Wording SGTM

[Oliver Chang, 2015-10-21 17:17:00]

If this looks OK to you, when should we start warning developers and land this,
Lei?

[Lei Zhang, 2015-10-21 17:23:46]

On 2015/10/21 17:17:00, Oliver Chang wrote:
> If this looks OK to you, when should we start warning developers and land
this,
> Lei?

lgtm

Would you like to email the external pdfium group? Include steps for converting
an existing repo:

mkdir repo
mv pdfium repo
rm repo/pdfium/.gclient_entries # will be regenerated, with a warning
mv repo/pdfium/.gclient repo
edit repo/.gclient and change "name: '.'" to "name: 'pdfium'"

[Oliver Chang, 2015-10-21 17:36:49]

Description was changed from

==========
Change DEPS hooks paths to include 'pdfium/'.

This will break existing checkouts where .gclient is inside the pdfium
dir, but needed so that buildbots can do runhooks.

R=thestig@chromium.org,tsepez@chromium.org,thakis@chromium.org
==========

to

==========
Change DEPS hooks paths to include 'pdfium/'.

This will break existing checkouts where .gclient is inside the pdfium
dir, but needed so that buildbots can do runhooks.

Instead of having a single pdfium directory, checkouts will now compromise of:
("repo" can be named anything)

repo/.gclient
repo/pdfium/.git
repo/pdfium/others...

To convert an existing checkout, do something like:

mkdir repo
mv pdfium repo
rm repo/pdfium/.gclient_entries # will be regenerated, with a warning
mv repo/pdfium/.gclient repo
edit repo/.gclient and change "name: '.'" to "name: 'pdfium'"

Instructions for getting a new checkout are in README.md in this CL.

R=thestig@chromium.org,tsepez@chromium.org,thakis@chromium.org
==========

[Oliver Chang, 2015-10-21 17:40:52]

Description was changed from

==========
Change DEPS hooks paths to include 'pdfium/'.

This will break existing checkouts where .gclient is inside the pdfium
dir, but needed so that buildbots can do runhooks.

Instead of having a single pdfium directory, checkouts will now compromise of:
("repo" can be named anything)

repo/.gclient
repo/pdfium/.git
repo/pdfium/others...

To convert an existing checkout, do something like:

mkdir repo
mv pdfium repo
rm repo/pdfium/.gclient_entries # will be regenerated, with a warning
mv repo/pdfium/.gclient repo
edit repo/.gclient and change "name: '.'" to "name: 'pdfium'"

Instructions for getting a new checkout are in README.md in this CL.

R=thestig@chromium.org,tsepez@chromium.org,thakis@chromium.org
==========

to

==========
Change DEPS hooks paths to include 'pdfium/'.

This will break existing checkouts based on the instructions proided.

Instead of having a single pdfium directory, checkouts will now compromise of:
("repo" can be named anything)

repo/.gclient
repo/pdfium/.git
repo/pdfium/others...

To convert an existing checkout, do something like:

mkdir repo
mv pdfium repo
rm repo/pdfium/.gclient_entries # will be regenerated, with a warning
mv repo/pdfium/.gclient repo
edit repo/.gclient and change "name: '.'" to "name: 'pdfium'"

Instructions for getting a new checkout are in README.md in this CL.

R=thestig@chromium.org,tsepez@chromium.org,thakis@chromium.org
==========

[Oliver Chang, 2015-10-21 17:40:59]

Description was changed from

==========
Change DEPS hooks paths to include 'pdfium/'.

This will break existing checkouts based on the instructions proided.

Instead of having a single pdfium directory, checkouts will now compromise of:
("repo" can be named anything)

repo/.gclient
repo/pdfium/.git
repo/pdfium/others...

To convert an existing checkout, do something like:

mkdir repo
mv pdfium repo
rm repo/pdfium/.gclient_entries # will be regenerated, with a warning
mv repo/pdfium/.gclient repo
edit repo/.gclient and change "name: '.'" to "name: 'pdfium'"

Instructions for getting a new checkout are in README.md in this CL.

R=thestig@chromium.org,tsepez@chromium.org,thakis@chromium.org
==========

to

==========
Change DEPS hooks paths to include 'pdfium/'.

This will break existing checkouts based on the instructions provided.

Instead of having a single pdfium directory, checkouts will now compromise of:
("repo" can be named anything)

repo/.gclient
repo/pdfium/.git
repo/pdfium/others...

To convert an existing checkout, do something like:

mkdir repo
mv pdfium repo
rm repo/pdfium/.gclient_entries # will be regenerated, with a warning
mv repo/pdfium/.gclient repo
edit repo/.gclient and change "name: '.'" to "name: 'pdfium'"

Instructions for getting a new checkout are in README.md in this CL.

R=thestig@chromium.org,tsepez@chromium.org,thakis@chromium.org
==========

[Oliver Chang, 2015-10-21 19:06:02]

Committed patchset #4 (id:60001) manually as
d0b794a102d1f37131c8f56c27f4a5fc9234a879 (presubmit successful).