| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TL;DR: resolve "C:/progra~1" style paths, don't
cache failed resolutions in the parent's
Path.children
When creating WindowsPath objects, resolve the
"C:/progra~1" style paths to "C:/program files".
This enables us to correctly compare paths on
Windows. Without this canonicalization we
incorrectly determine "C:/progra~1" and
"C:/program files" to be different when they are
actually the same.
We only attempt to resolve such paths if the name
looks like it's an abbreviated path.
If resolution fails, probably due to the path not
existing, then we don't cache this Path object in
the parent's `children` list. This avoids stale
cache entries in case the path springs into
existence later in the server's lifetime.
Fixes https://github.com/bazelbuild/bazel/issues/2145
We also need to rectify https://github.com/bazelbuild/bazel/issues/2173
--
PiperOrigin-RevId: 143442134
MOS_MIGRATED_REVID=143442134
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 142664504
MOS_MIGRATED_REVID=142664504
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implement a JNI method that can resolve 8dot3
style paths. This is necessary because we need to
be able to compare 8dot3 style paths and long
paths [1], and because implementing this correctly
in Java seems to be impossible [2].
This change also adds tests for the JNI isJunction
implementation.
See https://github.com/bazelbuild/bazel/issues/2101
[1] https://github.com/bazelbuild/bazel/issues/2145
[2] https://github.com/bazelbuild/bazel/issues/2145#issuecomment-266766716
--
PiperOrigin-RevId: 142123750
MOS_MIGRATED_REVID=142123750
|
|
|
|
|
|
|
|
|
|
|
| |
Also don't create "C:/first", tests don't
really need it.
Motivation: test failure in
http://ci.bazel.io/job/bazel-tests/BAZEL_VERSION=HEAD,PLATFORM_NAME=linux-x86_64/331/console
--
MOS_MIGRATED_REVID=139897644
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change updates WindowsFileSystem so it:
- retrieves the DosFileAttributes instead of the
BasicFileAttributes, because the latter does not
report junctions as directories
- uses just isJunction to decide if a file is a
symlink, doesn't look at whether it's a
directory (again because java.nio.File also
incorrectly reports junctions as
non-directories)
Fixes https://github.com/bazelbuild/bazel/issues/1850
--
MOS_MIGRATED_REVID=138187220
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When rewriting stable-status.txt, which happens on each build, avoid updating
the file's ctime and mtime if the new contents match what is already in the
file.
This prevents tickling the TimestampGranularityMonitor for what should be a
no-op update, which in turn could cause null/incremental builds to stall for
up to a second. The problem was magnified on macOS where the default HFS+
file system only has second-level granularity. (This also affects Linux, but
because current Linux file systems have milli/nanosecond-level granularity,
the wait imposed by TimestampGranularityMonitor is minimal and thus not
generally noticeable.)
--
MOS_MIGRATED_REVID=137983794
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PathFragment no longer parses "/c/foo" as "C:/foo"
on Windows, but as a driveletter-less absolute
path. If such a PathFragment is used in creating a
Path object, the WindowsPath.translatePath method
will translate it correctly.
Fixes https://github.com/bazelbuild/bazel/issues/1994
--
MOS_MIGRATED_REVID=137283176
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change rolls forward commit e0d7a540e3c615c628f63fcaaaba0c47fca2cb25 and
commit 8bb4299b28de14eed9d3b57bcaeb9350c81c7db3, and adds a bugfix:
- FileSystem.PathFactory got a new translatePath
method that WindowsFileSystem.PathFactory
overrides to translate absolute Unix paths to
MSYS-relative paths
- Path.getCachedChildPath calls this translatePath
method so the child path is registered with the
correct (translated) parent and under the
correct name (e.g. "C:" instead of say "c")
Below is the rest of the original change
description:
The new subclass WindowsFileSystem.WindowsPath is
aware of Windows drives.
This change:
- introduces a new factory for Path objects so
FileSystems can return a custom implementation
that instantiates filesystem-specific Paths
- implements the WindowsPath subclass of Path that
is aware of Windows drives
- introduces the bazel.windows_unix_root JVM
argument that defines the MSYS root, which
defines the absolute Windows path that is the
root of all Unix paths that Bazel creates (e.g.
"/usr/lib" -> "C:/tools/msys64/usr/lib") except
if the path is of the form "/c/foo" which is
treated as "C:/foo"
- removes all Windows-specific logic from Path
PathFragment is still aware of drive letters and
it has to remain so because it is unaware of file
systems.
WindowsPath restricts the allowed path strings to
absolute Unix paths where the first segment, if
any, is a volume specifier. From now on if Bazel
attempts to create a WindowsPath from an absolute
Unix path, Bazel will make it relative to
WindowsPath.UNIX_ROOT, unless the first component
is a single-letter name (e.g. "/c/foo" which is
"C:/foo").
Subclassing Path is necessary because a Unix-style
absolute path doesn't sufficiently define a full
Windows path, as it may be relative to any drive.
Fixes https://github.com/bazelbuild/bazel/issues/1463
--
MOS_MIGRATED_REVID=137149483
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Suspected root cause for Windows bootstrap on Bazel CI breakage:
java.lang.NullPointerException
at com.google.devtools.build.lib.vfs.Path$1.run(Path.java:123)
http://ci.bazel.io/view/Bazel%20bootstrap%20and%20maintenance/job/Bazel/922/JAVA_VERSION=1.8,PLATFORM_NAME=windows-x86_64/console
*** Original change description ***
VFS: implement a Windows-specific Path subclass
The new subclass WindowsFileSystem.WindowsPath is
aware of Windows drives.
This change:
- introduces a new factory for Path objects so
FileSystems can return a custom implementation
that instantiates filesystem-specific Paths
- implements the WindowsPath subclass of Path that
is aware of Windows drives
- introduces the bazel.windows_unix_root JVM
argument that defines the MSYS root, which
defines the absolute Windows path that is the...
***
--
MOS_MIGRATED_REVID=136583352
|
|
|
|
|
|
|
| |
RELNOTES[NEW]: Files now have an "extension" property in Skylark.
--
MOS_MIGRATED_REVID=136425934
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new subclass WindowsFileSystem.WindowsPath is
aware of Windows drives.
This change:
- introduces a new factory for Path objects so
FileSystems can return a custom implementation
that instantiates filesystem-specific Paths
- implements the WindowsPath subclass of Path that
is aware of Windows drives
- introduces the bazel.windows_unix_root JVM
argument that defines the MSYS root, which
defines the absolute Windows path that is the
root of all Unix paths that Bazel creates (e.g.
"/usr/lib" -> "C:/tools/msys64/usr/lib") except
if the path is of the form "/c/foo" which is
treated as "C:/foo"
- removes all Windows-specific logic from Path
PathFragment is still aware of drive letters and
it has to remain so because it is unaware of file
systems.
WindowsPath restricts the allowed path strings to
absolute Unix paths where the first segment, if
any, is a volume specifier. From now on if Bazel
attempts to create a WindowsPath from an absolute
Unix path, Bazel will make it relative to
WindowsPath.UNIX_ROOT, unless the first component
is a single-letter name (e.g. "/c/foo" which is
"C:/foo").
Subclassing Path is necessary because a Unix-style
absolute path doesn't sufficiently define a full
Windows path, as it may be relative to any drive.
Fixes https://github.com/bazelbuild/bazel/issues/1463
--
MOS_MIGRATED_REVID=136350304
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=133564429
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also add tests for WindowsFileSystem and some for
WindowsFileOperations, so we test both the
JNI-based and Java-native isJunction function, as
well as handling of dangling symlinks/junctions.
Having a Java-native version of this method means
we don't need to use windows_jni.dll for any tests
or for bootstrapping.
This change could help with
https://github.com/bazelbuild/bazel/issues/1735
--
MOS_MIGRATED_REVID=132556440
|
|
|
|
|
|
|
|
|
| |
decompresses tarballs.
Issue link: https://github.com/bazelbuild/bazel/issues/574
--
MOS_MIGRATED_REVID=132434278
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
manual rollback of []
*** Reason for rollback ***
Depot has been fixed / is in the process of being fixed. See the work tracked on []
*** Original change description ***
Automated [] rollback of commit bb5d5efb4b50710241b5b374eb67084f4bf08278.
--
MOS_MIGRATED_REVID=131095905
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=130941264
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sorted. Previously, it would return a list formed by concatenating the sorted results of each pattern in the 'includes' list.
A bunch of cleanups and one bug fix:
-Remove the unused-except-for tests GlobCache#globsUpToDate. This code has been dead for a very very long time, ever since we switched to using Skyframe.
-Change the semantics of the 'glob' function as described above.
-Change UnixGlob to return unsorted results. Document this in UnixGlob and GlobCache.
-Change LegacyGlobber to conditionally return sorted results. Have users other than PackageFunction get sorted results (as described above). Have PackageFunction's use case get completely unsorted results, and have PackageFunction do the sorting itself.
-Have PackageFunction's HybridGlobber unconditionally sort the glob result list. This ensure deterministic glob results, fixing a bug where the order of the elements of the result depended on the contents of the Skyframe graph, which of course depends on the sequence of incremental Blaze commands.
--
MOS_MIGRATED_REVID=130540152
|
|
|
|
|
|
|
| |
behavior (passing -1 modified time should use system time).
--
MOS_MIGRATED_REVID=128489592
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=125721556
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Newly passing:
//src/test/java/com/google/devtools/build/...
lib/skyframe:SkyframeTests
lib:actions_test
Also refactored FileSystems.java
--
Change-Id: I03ab9db5c1ab5e5be4ff1efbc5cf2d280084254a
Reviewed-on: https://bazel-review.googlesource.com/#/c/3843
MOS_MIGRATED_REVID=125449456
|
|
|
|
|
|
|
| |
Part 1 of many for #1262, rolling forward.
--
MOS_MIGRATED_REVID=125334954
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=125160288
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
repositories
One interesting side effect of how this is implemented is that for external
repositories, bin/ and genfiles/ are combined. External repo output is under
bazel-out/local-fastbuild/repo_name for each repo.
Fixes #1262.
RELNOTES[INC]: Previously, an external repository would be symlinked into the
execution root at execroot/local_repo/external/remote_repo. This changes it to
be at execroot/remote_repo. This may break genrules/Skylark actions that
hardcode execution root paths. If this causes breakages for you, ensure that
genrules are using $(location :target) to access files and Skylark rules are
using http://bazel.io/docs/skylark/lib/File.html's path, dirname, etc.
functions.
--
MOS_MIGRATED_REVID=125095799
|
|
|
|
|
|
|
| |
GlobTaskContext object. Also dedupe identical recursive calls that arise from our naive implementation of the glob algorithm.
--
MOS_MIGRATED_REVID=124159729
|
|
|
|
|
|
|
| |
around so that we still have good test coverage for 'excludes' in globs.
--
MOS_MIGRATED_REVID=124152499
|
|
|
|
|
|
|
|
|
| |
BlazeRuntime#getProductName() or a reference to TestConstants.PRODUCT_NAME for tests.
This CL prepares the codebase in order to delete the constant.
--
MOS_MIGRATED_REVID=122993568
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=122627792
|
|
|
|
|
|
|
|
| |
Since file path is case-insensitive on Windows, we need to support this.
Also fixed .d file inclusions check in CppCompileAction.java on Windows
--
MOS_MIGRATED_REVID=121823250
|
|
|
|
|
|
|
|
|
| |
package's package root when creating top-level directories. Otherwise, if the empty package references files in those top-level directories, they would be hidden.
Fixes #1221
--
MOS_MIGRATED_REVID=121392128
|
|
|
|
|
|
|
| |
This makes it possible to compile //third_party/ijar with a bootstrapped Bazel on Windows in dslomov's tree.
--
MOS_MIGRATED_REVID=114428109
|
|
|
|
|
|
|
| |
This helps avoid confusion with File*S*ystemUtils, which differs in only the case of a character but is a completely different class.
--
MOS_MIGRATED_REVID=113054116
|
|
|
|
|
|
|
| |
our plans for symlink support on Windows.
--
MOS_MIGRATED_REVID=113043269
|
|
|
|
|
|
|
| |
Reduces garbage.
--
MOS_MIGRATED_REVID=109914243
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=109081842
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=107492955
|
|
|
|
|
|
|
| |
instead.
--
MOS_MIGRATED_REVID=107480889
|
|
|
|
|
|
|
| |
FileStatus#isSpecialFile to help disambiguate between a regular file and a special file, since the file size of a special file cannot be trusted.
--
MOS_MIGRATED_REVID=105903622
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=105050723
|
|
|
|
|
|
|
|
|
|
|
| |
The headers were modified with
`find . -type f -exec 'sed' '-Ei' 's|Copyright 201([45]) Google|Copyright 201\1 The Bazel Authors|' '{}' ';'`
And manual edit for not Google owned copyright. Because of the nature of ijar, I did not modified the header of file owned by Alan Donovan.
The list of authors were extracted from the git log. It is missing older Google contributors that can be added on-demand.
--
MOS_MIGRATED_REVID=103938715
|
|
|
|
|
|
|
| |
always true in practice.
--
MOS_MIGRATED_REVID=103221081
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=103090211
|
|
|
|
|
|
|
| |
Fixes #375
--
MOS_MIGRATED_REVID=100581187
|
|
|
|
|
|
|
| |
interrupted result implies that the thread pool is idle.
--
MOS_MIGRATED_REVID=97125559
|
|
|
|
|
|
|
| |
Also adds tests for it.
--
MOS_MIGRATED_REVID=96572991
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=96204334
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=95102460
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=95097699
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=95036998
|
|
|
|
|
|
|
| |
directories, as is specified in various places, not one or more.
--
MOS_MIGRATED_REVID=93758086
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=93647914
|