Set ZERO_AR_DATE=1 when running libtool.

Set ZERO_AR_DATE=1 when running libtool.

Ref: http://www.opensource.apple.com/source/cctools/cctools-809/misc/libtool.c

Adhoc testing with base_unittests reduced non-deterministic bytes from ~2347 to
~174. It's definitely the lowest hanging fruit, which will permit us to focus on
the remaining bytes.

R=thakis@chromium.org
BUG=chromium:330262
Committed: https://code.google.com/p/gyp/source/detail?r=1998

[Nico, 2014-11-04 18:31:43]

Do you know if this date is used for anything? Like, maybe incremental writing
of these files – I could imagine that it compares the timestamp in the archive
to each .o file and only copies stuff in that's newer, to save on libtool time.
Did you do any build profiling with this set?

[M-A Ruel, 2014-11-04 19:04:25]

On 2014/11/04 18:31:43, Nico wrote:
> Do you know if this date is used for anything? Like, maybe incremental writing
> of these files – I could imagine that it compares the timestamp in the
archive
> to each .o file and only copies stuff in that's newer, to save on libtool
time.
> Did you do any build profiling with this set?

Well that's borderline torture on a MBP without goma setup but here it is;

--- Without patch ---
$ rm -rf out
$ echo $GYP_DEFINES
component=shared_library clang=1 fastbuild=1 dcheck_always_on=1
$ gclient runhooks
$ time ninja -C out/Release base_unittests
ninja: Entering directory `out/Release'
[953/953] LINK base_unittests, POSTBUILDS

(First try clobber)
real    3m49.283s
user    22m52.358s
sys     1m23.265s

(Second try clobber)
real    3m12.276s
user    22m0.186s
sys     1m16.448s

$ time ninja -C out/Release base_unittests
ninja: Entering directory `out/Release'
ninja: no work to do.

real    0m0.362s
user    0m0.321s
sys     0m0.039s



--- With patch ---
$ rm -rf out
$ cd tools/gyp
$ git co 1_AR
$ cd ../..
$ gclient runhooks
$ time ninja -C out/Release base_unittests
ninja: Entering directory `out/Release'
[953/953] LINK base_unittests, POSTBUILDS

real    3m24.447s
user    22m14.069s
sys     1m18.575s
$ time ninja -C out/Release base_unittests
ninja: Entering directory `out/Release'
[20/20] LINK base_unittests, POSTBUILDS

real    0m1.298s
user    0m1.854s
sys     0m0.885s

I'm mostly surprised that 20 steps are rerun on a null build. :( FML.

[Nico, 2014-11-04 19:27:45]

I guess the interesting bit is "in a static build, touch a single file that ends
up in a .a file, and rebuild". base/ is maybe not the best target for that as it
also triggers nacl builds. I tend to use ui/ for this.

…I guess I can patch this in myself and check, one sec…

[Nico, 2014-11-04 19:28:46]

> …I guess I can patch this in myself and check, one sec…

…actually, senorblanco just reclaimed his power plug, and I don't know when I'll
have power again (at blinkon; power plugs are scarce), so I'll wait a bit with
that.

(ps: can you file a bug for the non-empty rebuild? :-( :-( :-( )

[M-A Ruel, 2014-11-04 19:39:05]

On 2014/11/04 19:28:46, Nico wrote:
> > …I guess I can patch this in myself and check, one sec…
> 
> …actually, senorblanco just reclaimed his power plug, and I don't know when
I'll
> have power again (at blinkon; power plugs are scarce), so I'll wait a bit with
> that.
> 
> (ps: can you file a bug for the non-empty rebuild? :-( :-( :-( )

I found the problem, it's trivial as I read the reference, the code call utime
even when st_mtime is set to 0. So all .a are reset to 1969. Congrats, guys.

Anyway the fix would be to call utime right after but I don't know how to get
the file name from the command line without hacky argument parsing.

[M-A Ruel, 2014-11-04 19:53:27]

On 2014/11/04 19:39:05, M-A Ruel wrote:
> On 2014/11/04 19:28:46, Nico wrote:
> > > …I guess I can patch this in myself and check, one sec…
> > 
> > …actually, senorblanco just reclaimed his power plug, and I don't know when
> I'll
> > have power again (at blinkon; power plugs are scarce), so I'll wait a bit
with
> > that.
> > 
> > (ps: can you file a bug for the non-empty rebuild? :-( :-( :-( )
> 
> I found the problem, it's trivial as I read the reference, the code call utime
> even when st_mtime is set to 0. So all .a are reset to 1969. Congrats, guys.
> 
> Anyway the fix would be to call utime right after but I don't know how to get
> the file name from the command line without hacky argument parsing.

Patchset #3 contains a working "hack".

[Nico, 2014-11-04 20:46:09]

Eww, but since gyp controls the libtool line I guess it's fine.

Please add a test that checks that the new mtime stuff works (see test/mac for
tons of example tests).

https://codereview.chromium.org/699083004/diff/40001/pylib/gyp/mac_tool.py
File pylib/gyp/mac_tool.py (right):

https://codereview.chromium.org/699083004/diff/40001/pylib/gyp/mac_tool.py#ne...
pylib/gyp/mac_tool.py:237: # Inconditionally touch any file .a file on the
command line if present if
Unconditionally

[M-A Ruel, 2014-11-05 02:51:05]

https://codereview.chromium.org/699083004/diff/40001/pylib/gyp/mac_tool.py
File pylib/gyp/mac_tool.py (right):

https://codereview.chromium.org/699083004/diff/40001/pylib/gyp/mac_tool.py#ne...
pylib/gyp/mac_tool.py:237: # Inconditionally touch any file .a file on the
command line if present if
On 2014/11/04 20:46:09, Nico wrote:
> Unconditionally

Done.

https://codereview.chromium.org/699083004/diff/80001/pylib/gyp/mac_tool.py
File pylib/gyp/mac_tool.py (right):

https://codereview.chromium.org/699083004/diff/80001/pylib/gyp/mac_tool.py#ne...
pylib/gyp/mac_tool.py:246: os.utime(archives[0], None)
I confirmed by running the test with:
./gyptest.py test/mac/gyptest-libtool-zero.py 

then commenting out this line and running the test again.

When run again, ninja and make failed, xcode still passed.

[Nico, 2014-11-05 07:10:15]

lgtm

This is looking great, thanks :-) Let's land it and see if it breaks anything.

[Nico, 2014-11-05 07:11:20]

(+rsesek who sometimes spelunks in this areas and might think that this is cute.
Also, if this ends up breaking something it's probably good if he knows about
this.)

[M-A Ruel, 2014-11-05 11:24:24]

The CQ bit was checked by maruel@chromium.org

[M-A Ruel, 2014-11-05 11:24:33]

The CQ bit was unchecked by maruel@chromium.org

[M-A Ruel, 2014-11-05 11:24:35]

The CQ bit was checked by maruel@chromium.org

[commit-bot: I haz the power, 2014-11-05 11:24:43]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-11-05 11:24:44]

Commit queue rejected this change because it did not recognize the base URL.
Please commit your change manually.

[M-A Ruel, 2014-11-05 12:53:30]

The CQ bit was checked by maruel@chromium.org

[commit-bot: I haz the power, 2014-11-05 12:54:59]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-11-05 12:54:59]

Commit queue rejected this change because it did not recognize the base URL.
Please commit your change manually.

[M-A Ruel, 2014-11-05 13:09:19]

I ran git cl try but no job started. Oops.

I happen to be a committer, should I simply commit and hope for the best? (Well,
it's not that bad, I actually ran the test)

[M-A Ruel, 2014-11-05 14:43:16]

http://build.chromium.org/p/tryserver.nacl/builders/gyp-android/builds/1076
blew up

http://build.chromium.org/p/tryserver.nacl/builders/gyp-win32/builds/1962
green

http://build.chromium.org/p/tryserver.nacl/builders/gyp-linux/builds/1888
green

http://build.chromium.org/p/tryserver.nacl/builders/gyp-mac/builds/1916
ninja
Failed the following 2 tests:
	test/mac/gyptest-archs.py
	test/product/gyptest-product.py
make
Failed the following test:
	test/product/gyptest-product.py

I ran the following;
./gyptest.py test/mac/gyptest-archs.py
and it hung (even without patch)

./gyptest.py test/product/gyptest-product.py passes without the patch and fails
with patch. Checking.

[M-A Ruel, 2014-11-05 14:50:02]

Fixed test/product/gyptest-product.py because it does:
test.built_file_must_exist(test.dll_ + 'hello5.stuff',
                           test.SHARED_LIB, bare=True)
test.built_file_must_exist('yoalt6.stuff', test.SHARED_LIB, bare=True)

which explicitly do not use test._dll extension. In this case, well, that's
their choice but that's weird.

[M-A Ruel, 2014-11-05 19:10:15]

On 2014/11/05 14:50:02, M-A Ruel wrote:
> Fixed test/product/gyptest-product.py because it does:
> test.built_file_must_exist(test.dll_ + 'hello5.stuff',
>                            test.SHARED_LIB, bare=True)
> test.built_file_must_exist('yoalt6.stuff', test.SHARED_LIB, bare=True)
> 
> which explicitly do not use test._dll extension. In this case, well, that's
> their choice but that's weird.

Rerunning on gyp-mac worked. I can't run the test locally even without the patch

[Nico, 2014-11-05 19:13:15]

still lgtm

What does the test fail with for you locally? What happens when you run `xcrun
-show-sdk-path`? Does it say something about accepting some eula?

[M-A Ruel, 2014-11-05 19:16:44]

On 2014/11/05 19:13:15, Nico wrote:
> still lgtm

Thanks

> What does the test fail with for you locally? What happens when you run `xcrun
> -show-sdk-path`? Does it say something about accepting some eula?

$ xcrun -show-sdk-path
xcrun: error: unrecognized option: -show-sdk-path

$ xcodebuild -version
Xcode 4.6

I guess it's time to upgrade. :D I hadn't realized I wasn't on 5.x.

[M-A Ruel, 2014-11-05 20:00:36]

Committed patchset #6 (id:100001) manually as 1998 (presubmit successful).