Use a stable ordering when enumerating files.

Use a stable ordering when enumerating files.

Output the enumerated files in sorted order when running enumerate_files.py
from gyp, to prevent unnecessary buildfile churn that makes comparing
revisions noisy.

BUG=

[Torne (Richard Coles), 2014-02-24 12:27:34]

Hi Geoff,

Would you mind taking this patch to make enumerate_files output stable? It
generates spurious differences when comparing revisions, otherwise.

Alternatively: is there a reason why you use this approach instead of just
listing all the files in the gyp files as chromium does? Running this code at
gyp time slows gyp down for everyone on chromium..

[Geoff Lang, 2014-02-24 14:40:34]

On 2014/02/24 12:27:34, Torne (Richard Coles) wrote:
> Hi Geoff,
> 
> Would you mind taking this patch to make enumerate_files output stable? It
> generates spurious differences when comparing revisions, otherwise.
> 
> Alternatively: is there a reason why you use this approach instead of just
> listing all the files in the gyp files as chromium does? Running this code at
> gyp time slows gyp down for everyone on chromium..

Hey,

Yep, I can land this patch, I'll have to make another review in Gerrit though.

I wrote this script since we were having difficulties maintaining the gyp files
and the generated visual studio projects in sync, resulting in several commits
that wouldn't build.  I tested on my system at the time and found that the
difference between using the enumerate_files script and manually listing the
files was less than 10 ms for a gclient runhooks.  That said, it might make more
sense to go back to the manual listing, we've found a few drawbacks such as
emacs generating temporary files with .cpp or .h extensions.

[Torne (Richard Coles), 2014-02-24 14:43:44]

On 2014/02/24 14:40:34, Geoff Lang wrote:
> On 2014/02/24 12:27:34, Torne (Richard Coles) wrote:
> > Hi Geoff,
> > 
> > Would you mind taking this patch to make enumerate_files output stable? It
> > generates spurious differences when comparing revisions, otherwise.
> > 
> > Alternatively: is there a reason why you use this approach instead of just
> > listing all the files in the gyp files as chromium does? Running this code
at
> > gyp time slows gyp down for everyone on chromium..
> 
> Hey,
> 
> Yep, I can land this patch, I'll have to make another review in Gerrit though.

No problem, sorry, I wasn't sure where to upload this.

> I wrote this script since we were having difficulties maintaining the gyp
files
> and the generated visual studio projects in sync, resulting in several commits
> that wouldn't build.  I tested on my system at the time and found that the
> difference between using the enumerate_files script and manually listing the
> files was less than 10 ms for a gclient runhooks.  That said, it might make
more
> sense to go back to the manual listing, we've found a few drawbacks such as
> emacs generating temporary files with .cpp or .h extensions.

There's a bunch of other possible problems as well, like accidentally including
code you don't mean to if you check out a different branch while working on
something else (untracked files will stay there).. it's up to you what you do
here, though.

[Torne (Richard Coles), 2014-02-24 14:45:04]

On 2014/02/24 14:43:44, Torne (Richard Coles) wrote:
> On 2014/02/24 14:40:34, Geoff Lang wrote:
> > On 2014/02/24 12:27:34, Torne (Richard Coles) wrote:
> > > Hi Geoff,
> > > 
> > > Would you mind taking this patch to make enumerate_files output stable? It
> > > generates spurious differences when comparing revisions, otherwise.
> > > 
> > > Alternatively: is there a reason why you use this approach instead of just
> > > listing all the files in the gyp files as chromium does? Running this code
> at
> > > gyp time slows gyp down for everyone on chromium..
> > 
> > Hey,
> > 
> > Yep, I can land this patch, I'll have to make another review in Gerrit
though.
> 
> No problem, sorry, I wasn't sure where to upload this.

Actually, just should also point out: there is a codereview.settings file in
your project that tells the chromium tools to upload changes here. If your
canonical repo is somewhere else you should probably change that. It is possible
to specify a git project and have it upload to gerrit, though I don't know an
example you can copy :)

> 
> > I wrote this script since we were having difficulties maintaining the gyp
> files
> > and the generated visual studio projects in sync, resulting in several
commits
> > that wouldn't build.  I tested on my system at the time and found that the
> > difference between using the enumerate_files script and manually listing the
> > files was less than 10 ms for a gclient runhooks.  That said, it might make
> more
> > sense to go back to the manual listing, we've found a few drawbacks such as
> > emacs generating temporary files with .cpp or .h extensions.
> 
> There's a bunch of other possible problems as well, like accidentally
including
> code you don't mean to if you check out a different branch while working on
> something else (untracked files will stay there).. it's up to you what you do
> here, though.

[Geoff Lang, 2014-02-24 14:49:39]

On 2014/02/24 14:45:04, Torne (Richard Coles) wrote:
> On 2014/02/24 14:43:44, Torne (Richard Coles) wrote:
> > On 2014/02/24 14:40:34, Geoff Lang wrote:
> > > On 2014/02/24 12:27:34, Torne (Richard Coles) wrote:
> > > > Hi Geoff,
> > > > 
> > > > Would you mind taking this patch to make enumerate_files output stable?
It
> > > > generates spurious differences when comparing revisions, otherwise.
> > > > 
> > > > Alternatively: is there a reason why you use this approach instead of
just
> > > > listing all the files in the gyp files as chromium does? Running this
code
> > at
> > > > gyp time slows gyp down for everyone on chromium..
> > > 
> > > Hey,
> > > 
> > > Yep, I can land this patch, I'll have to make another review in Gerrit
> though.
> > 
> > No problem, sorry, I wasn't sure where to upload this.
> 
> Actually, just should also point out: there is a codereview.settings file in
> your project that tells the chromium tools to upload changes here. If your
> canonical repo is somewhere else you should probably change that. It is
possible
> to specify a git project and have it upload to gerrit, though I don't know an
> example you can copy :)
> 
> > 
> > > I wrote this script since we were having difficulties maintaining the gyp
> > files
> > > and the generated visual studio projects in sync, resulting in several
> commits
> > > that wouldn't build.  I tested on my system at the time and found that the
> > > difference between using the enumerate_files script and manually listing
the
> > > files was less than 10 ms for a gclient runhooks.  That said, it might
make
> > more
> > > sense to go back to the manual listing, we've found a few drawbacks such
as
> > > emacs generating temporary files with .cpp or .h extensions.
> > 
> > There's a bunch of other possible problems as well, like accidentally
> including
> > code you don't mean to if you check out a different branch while working on
> > something else (untracked files will stay there).. it's up to you what you
do
> > here, though.

Yea, the codereview.settings needs to be removed.  Pushing to gerrit is a little
different though, you should only have to 'git push origin
master:refs/for/master' using the username and password generated at
https://chromium.googlesource.com/

[Torne (Richard Coles), 2014-02-24 14:51:33]

On 2014/02/24 14:49:39, Geoff Lang wrote:
> On 2014/02/24 14:45:04, Torne (Richard Coles) wrote:
> > On 2014/02/24 14:43:44, Torne (Richard Coles) wrote:
> > > On 2014/02/24 14:40:34, Geoff Lang wrote:
> > > > On 2014/02/24 12:27:34, Torne (Richard Coles) wrote:
> > > > > Hi Geoff,
> > > > > 
> > > > > Would you mind taking this patch to make enumerate_files output
stable?
> It
> > > > > generates spurious differences when comparing revisions, otherwise.
> > > > > 
> > > > > Alternatively: is there a reason why you use this approach instead of
> just
> > > > > listing all the files in the gyp files as chromium does? Running this
> code
> > > at
> > > > > gyp time slows gyp down for everyone on chromium..
> > > > 
> > > > Hey,
> > > > 
> > > > Yep, I can land this patch, I'll have to make another review in Gerrit
> > though.
> > > 
> > > No problem, sorry, I wasn't sure where to upload this.
> > 
> > Actually, just should also point out: there is a codereview.settings file in
> > your project that tells the chromium tools to upload changes here. If your
> > canonical repo is somewhere else you should probably change that. It is
> possible
> > to specify a git project and have it upload to gerrit, though I don't know
an
> > example you can copy :)
> > 
> > > 
> > > > I wrote this script since we were having difficulties maintaining the
gyp
> > > files
> > > > and the generated visual studio projects in sync, resulting in several
> > commits
> > > > that wouldn't build.  I tested on my system at the time and found that
the
> > > > difference between using the enumerate_files script and manually listing
> the
> > > > files was less than 10 ms for a gclient runhooks.  That said, it might
> make
> > > more
> > > > sense to go back to the manual listing, we've found a few drawbacks such
> as
> > > > emacs generating temporary files with .cpp or .h extensions.
> > > 
> > > There's a bunch of other possible problems as well, like accidentally
> > including
> > > code you don't mean to if you check out a different branch while working
on
> > > something else (untracked files will stay there).. it's up to you what you
> do
> > > here, though.
> 
> Yea, the codereview.settings needs to be removed.  Pushing to gerrit is a
little
> different though, you should only have to 'git push origin
> master:refs/for/master' using the username and password generated at
> https://chromium.googlesource.com/

It is a little different, but if you configure codereview.settings correctly
then "git cl upload" will do the right thing for you (it will push to
refs/for/master). This works in other projects, but I can't find an example for
you right now :)

Just suggesting it, as it would make uploading small patches like this easier
for chromium engineers who don't work on your project.

[Shannon Woods, 2014-02-24 14:54:07]

On 2014/02/24 14:51:33, Torne (Richard Coles) wrote:
> On 2014/02/24 14:49:39, Geoff Lang wrote:
> > On 2014/02/24 14:45:04, Torne (Richard Coles) wrote:
> > > On 2014/02/24 14:43:44, Torne (Richard Coles) wrote:
> > > > On 2014/02/24 14:40:34, Geoff Lang wrote:
> > > > > On 2014/02/24 12:27:34, Torne (Richard Coles) wrote:
> > > > > > Hi Geoff,
> > > > > > 
> > > > > > Would you mind taking this patch to make enumerate_files output
> stable?
> > It
> > > > > > generates spurious differences when comparing revisions, otherwise.
> > > > > > 
> > > > > > Alternatively: is there a reason why you use this approach instead
of
> > just
> > > > > > listing all the files in the gyp files as chromium does? Running
this
> > code
> > > > at
> > > > > > gyp time slows gyp down for everyone on chromium..
> > > > > 
> > > > > Hey,
> > > > > 
> > > > > Yep, I can land this patch, I'll have to make another review in Gerrit
> > > though.
> > > > 
> > > > No problem, sorry, I wasn't sure where to upload this.
> > > 
> > > Actually, just should also point out: there is a codereview.settings file
in
> > > your project that tells the chromium tools to upload changes here. If your
> > > canonical repo is somewhere else you should probably change that. It is
> > possible
> > > to specify a git project and have it upload to gerrit, though I don't know
> an
> > > example you can copy :)
> > > 
> > > > 
> > > > > I wrote this script since we were having difficulties maintaining the
> gyp
> > > > files
> > > > > and the generated visual studio projects in sync, resulting in several
> > > commits
> > > > > that wouldn't build.  I tested on my system at the time and found that
> the
> > > > > difference between using the enumerate_files script and manually
listing
> > the
> > > > > files was less than 10 ms for a gclient runhooks.  That said, it might
> > make
> > > > more
> > > > > sense to go back to the manual listing, we've found a few drawbacks
such
> > as
> > > > > emacs generating temporary files with .cpp or .h extensions.
> > > > 
> > > > There's a bunch of other possible problems as well, like accidentally
> > > including
> > > > code you don't mean to if you check out a different branch while working
> on
> > > > something else (untracked files will stay there).. it's up to you what
you
> > do
> > > > here, though.
> > 
> > Yea, the codereview.settings needs to be removed.  Pushing to gerrit is a
> little
> > different though, you should only have to 'git push origin
> > master:refs/for/master' using the username and password generated at
> > https://chromium.googlesource.com/
> 
> It is a little different, but if you configure codereview.settings correctly
> then "git cl upload" will do the right thing for you (it will push to
> refs/for/master). This works in other projects, but I can't find an example
for
> you right now :)
> 
> Just suggesting it, as it would make uploading small patches like this easier
> for chromium engineers who don't work on your project.

That would probably be a good idea. In the meantime, how to upload patches for
review is documented at:
https://code.google.com/p/angleproject/wiki/ContributingCode

[Geoff Lang, 2014-02-24 15:15:02]

On 2014/02/24 14:54:07, Shannon Woods wrote:
> On 2014/02/24 14:51:33, Torne (Richard Coles) wrote:
> > On 2014/02/24 14:49:39, Geoff Lang wrote:
> > > On 2014/02/24 14:45:04, Torne (Richard Coles) wrote:
> > > > On 2014/02/24 14:43:44, Torne (Richard Coles) wrote:
> > > > > On 2014/02/24 14:40:34, Geoff Lang wrote:
> > > > > > On 2014/02/24 12:27:34, Torne (Richard Coles) wrote:
> > > > > > > Hi Geoff,
> > > > > > > 
> > > > > > > Would you mind taking this patch to make enumerate_files output
> > stable?
> > > It
> > > > > > > generates spurious differences when comparing revisions,
otherwise.
> > > > > > > 
> > > > > > > Alternatively: is there a reason why you use this approach instead
> of
> > > just
> > > > > > > listing all the files in the gyp files as chromium does? Running
> this
> > > code
> > > > > at
> > > > > > > gyp time slows gyp down for everyone on chromium..
> > > > > > 
> > > > > > Hey,
> > > > > > 
> > > > > > Yep, I can land this patch, I'll have to make another review in
Gerrit
> > > > though.
> > > > > 
> > > > > No problem, sorry, I wasn't sure where to upload this.
> > > > 
> > > > Actually, just should also point out: there is a codereview.settings
file
> in
> > > > your project that tells the chromium tools to upload changes here. If
your
> > > > canonical repo is somewhere else you should probably change that. It is
> > > possible
> > > > to specify a git project and have it upload to gerrit, though I don't
know
> > an
> > > > example you can copy :)
> > > > 
> > > > > 
> > > > > > I wrote this script since we were having difficulties maintaining
the
> > gyp
> > > > > files
> > > > > > and the generated visual studio projects in sync, resulting in
several
> > > > commits
> > > > > > that wouldn't build.  I tested on my system at the time and found
that
> > the
> > > > > > difference between using the enumerate_files script and manually
> listing
> > > the
> > > > > > files was less than 10 ms for a gclient runhooks.  That said, it
might
> > > make
> > > > > more
> > > > > > sense to go back to the manual listing, we've found a few drawbacks
> such
> > > as
> > > > > > emacs generating temporary files with .cpp or .h extensions.
> > > > > 
> > > > > There's a bunch of other possible problems as well, like accidentally
> > > > including
> > > > > code you don't mean to if you check out a different branch while
working
> > on
> > > > > something else (untracked files will stay there).. it's up to you what
> you
> > > do
> > > > > here, though.
> > > 
> > > Yea, the codereview.settings needs to be removed.  Pushing to gerrit is a
> > little
> > > different though, you should only have to 'git push origin
> > > master:refs/for/master' using the username and password generated at
> > > https://chromium.googlesource.com/
> > 
> > It is a little different, but if you configure codereview.settings correctly
> > then "git cl upload" will do the right thing for you (it will push to
> > refs/for/master). This works in other projects, but I can't find an example
> for
> > you right now :)
> > 
> > Just suggesting it, as it would make uploading small patches like this
easier
> > for chromium engineers who don't work on your project.
> 
> That would probably be a good idea. In the meantime, how to upload patches for
> review is documented at:
> https://code.google.com/p/angleproject/wiki/ContributingCode

Put the CL up here: https://chromium-review.googlesource.com/#/c/187533