6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2024-11-06 21:05:51 +00:00
Code Issues Projects Releases Wiki Activity
ae618e7873
llvm-6502/test/Object/archive-update.test

36 lines
1.1 KiB
Plaintext
Raw Normal View History

Add a test for llvm-ar's u option. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186192 91177308-0d34-0410-b5e6-96231b3b80d8
2013-07-12 19:34:24 +00:00
Test the 'u' option of llvm-ar
RUN: cd %T
RUN: rm -f %t.a
Change archive-update.test to create a new file on the fly. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186206 91177308-0d34-0410-b5e6-96231b3b80d8
2013-07-12 21:17:17 +00:00
Create a file named evenlen that is newer than the evenlen on the source dir.
The archive update test has a subtle race condition in it: if the test is executed within the same second as the inputs for the test are checked out from the source tree, it will fail to update due to being below the resolution of the 'mtime' test used. Now, this may seem improbably to you... ok, maybe *really* improbable, but consider a system which does distributed execution of tests by shipping their inputs to another machine and runs them. That might cause the mtime to be quite recent during the test run. ;] Instead, create two files directly in the test (allowing all platforms to see the problem) and add either a use of the 'touch' command that forces one mtime to some time quite a bit in the past, or it sleeps for just over a second to be outside of the precision window. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186282 91177308-0d34-0410-b5e6-96231b3b80d8
2013-07-14 10:46:51 +00:00
RUN: mkdir -p %t.older
RUN: echo older > %t.older/evenlen
Either the shell supports the 'touch' command with a flag to manually set the
mtime or we sleep for over a second so that the mtime is definitely observable.
RUN: touch -m -t 200001010000 %t.older/evenlen || sleep 1.1
RUN: mkdir -p %t.newer
RUN: echo newer > %t.newer/evenlen
RUN: touch %t.newer/evenlen
Change archive-update.test to create a new file on the fly. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186206 91177308-0d34-0410-b5e6-96231b3b80d8
2013-07-12 21:17:17 +00:00
Add a test for llvm-ar's u option. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186192 91177308-0d34-0410-b5e6-96231b3b80d8
2013-07-12 19:34:24 +00:00
Create an achive with the newest file
The archive update test has a subtle race condition in it: if the test is executed within the same second as the inputs for the test are checked out from the source tree, it will fail to update due to being below the resolution of the 'mtime' test used. Now, this may seem improbably to you... ok, maybe *really* improbable, but consider a system which does distributed execution of tests by shipping their inputs to another machine and runs them. That might cause the mtime to be quite recent during the test run. ;] Instead, create two files directly in the test (allowing all platforms to see the problem) and add either a use of the 'touch' command that forces one mtime to some time quite a bit in the past, or it sleeps for just over a second to be outside of the precision window. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186282 91177308-0d34-0410-b5e6-96231b3b80d8
2013-07-14 10:46:51 +00:00
RUN: llvm-ar r %t.a %t.newer/evenlen
Add a test for llvm-ar's u option. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186192 91177308-0d34-0410-b5e6-96231b3b80d8
2013-07-12 19:34:24 +00:00
RUN: llvm-ar p %t.a | FileCheck --check-prefix=NEWER %s
Check that without the 'u' option the member is replaced with an older file.
The archive update test has a subtle race condition in it: if the test is executed within the same second as the inputs for the test are checked out from the source tree, it will fail to update due to being below the resolution of the 'mtime' test used. Now, this may seem improbably to you... ok, maybe *really* improbable, but consider a system which does distributed execution of tests by shipping their inputs to another machine and runs them. That might cause the mtime to be quite recent during the test run. ;] Instead, create two files directly in the test (allowing all platforms to see the problem) and add either a use of the 'touch' command that forces one mtime to some time quite a bit in the past, or it sleeps for just over a second to be outside of the precision window. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186282 91177308-0d34-0410-b5e6-96231b3b80d8
2013-07-14 10:46:51 +00:00
RUN: llvm-ar r %t.a %t.older/evenlen
Add a test for llvm-ar's u option. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186192 91177308-0d34-0410-b5e6-96231b3b80d8
2013-07-12 19:34:24 +00:00
RUN: llvm-ar p %t.a | FileCheck --check-prefix=OLDER %s
Check that with the 'u' option the member is replaced with a newer file.
The archive update test has a subtle race condition in it: if the test is executed within the same second as the inputs for the test are checked out from the source tree, it will fail to update due to being below the resolution of the 'mtime' test used. Now, this may seem improbably to you... ok, maybe *really* improbable, but consider a system which does distributed execution of tests by shipping their inputs to another machine and runs them. That might cause the mtime to be quite recent during the test run. ;] Instead, create two files directly in the test (allowing all platforms to see the problem) and add either a use of the 'touch' command that forces one mtime to some time quite a bit in the past, or it sleeps for just over a second to be outside of the precision window. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186282 91177308-0d34-0410-b5e6-96231b3b80d8
2013-07-14 10:46:51 +00:00
RUN: llvm-ar ru %t.a %t.newer/evenlen
Add a test for llvm-ar's u option. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186192 91177308-0d34-0410-b5e6-96231b3b80d8
2013-07-12 19:34:24 +00:00
RUN: llvm-ar p %t.a | FileCheck --check-prefix=NEWER %s
Check that with the 'u' option the member is not replaced with an older file.
The archive update test has a subtle race condition in it: if the test is executed within the same second as the inputs for the test are checked out from the source tree, it will fail to update due to being below the resolution of the 'mtime' test used. Now, this may seem improbably to you... ok, maybe *really* improbable, but consider a system which does distributed execution of tests by shipping their inputs to another machine and runs them. That might cause the mtime to be quite recent during the test run. ;] Instead, create two files directly in the test (allowing all platforms to see the problem) and add either a use of the 'touch' command that forces one mtime to some time quite a bit in the past, or it sleeps for just over a second to be outside of the precision window. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186282 91177308-0d34-0410-b5e6-96231b3b80d8
2013-07-14 10:46:51 +00:00
RUN: llvm-ar ru %t.a %t.older/evenlen
Add a test for llvm-ar's u option. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186192 91177308-0d34-0410-b5e6-96231b3b80d8
2013-07-12 19:34:24 +00:00
RUN: llvm-ar p %t.a | FileCheck --check-prefix=NEWER %s
NEWER: newer
The archive update test has a subtle race condition in it: if the test is executed within the same second as the inputs for the test are checked out from the source tree, it will fail to update due to being below the resolution of the 'mtime' test used. Now, this may seem improbably to you... ok, maybe *really* improbable, but consider a system which does distributed execution of tests by shipping their inputs to another machine and runs them. That might cause the mtime to be quite recent during the test run. ;] Instead, create two files directly in the test (allowing all platforms to see the problem) and add either a use of the 'touch' command that forces one mtime to some time quite a bit in the past, or it sleeps for just over a second to be outside of the precision window. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186282 91177308-0d34-0410-b5e6-96231b3b80d8
2013-07-14 10:46:51 +00:00
OLDER: older
Reference in New Issue Copy Permalink