| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
|
|
|
|
|
|
| |
- if there are failed top-level aspects
- if there are conflicting actions
I ended up rewriting how errors are signaled from the SkyframeBuildView. I
think this is safe, but please review carefully.
--
MOS_MIGRATED_REVID=113150100
|
|
|
|
|
|
|
|
|
|
| |
This just requires passing the specified deps through to the java_import
wrapping the Groovy jar
--
Change-Id: Ib453d560a721fdb31217f8e604703fa6bc362328
Reviewed-on: https://bazel-review.googlesource.com/2600
MOS_MIGRATED_REVID=113149555
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=113139138
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=113137648
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Dependencies are the data structure which needs to propagate the configuration for each
aspect as created by trimConfigurations down to the point where it's actually used. We
need this to store different configurations for different aspects in a world where aspects
have their own configurations, which may have more fragments than the target they're
attached to.
That world is on its way.
Also in this CL:
* Refactor Dependency to be an abstract parent class with separate implementations for
Attribute.Transitions and BuildConfigurations, as well as null configurations, to avoid
having to check nullness in various places. Users of the API will not see this, but get
factory methods instead of constructors. As a consequence of this, refactor Dependency
to be its own top-level class instead of a nested class in DependencyResolver.
--
MOS_MIGRATED_REVID=113109615
|
|
|
|
|
|
|
|
|
|
|
| |
This creates a JackAspect which is calculated for Java dependencies of
Android libraries and binaries and their Java dependencies.
Note that this only applies to java_library and java_import at this time
because they are the only ones exporting the necessary provider.
--
MOS_MIGRATED_REVID=113107408
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=113105947
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=113081497
|
|
|
|
|
|
|
|
|
|
| |
We're restricted repository names in preparation for improving the runfiles
situation.
RELNOTES: j2objc tools can now be accessed via @bazel_j2objc, not @bazel-j2objc.
--
MOS_MIGRATED_REVID=113071304
|
|
|
|
|
|
|
|
| |
RELNOTES: JDK-related targets are now available via @local_jdk (instead of
@local-jdk).
--
MOS_MIGRATED_REVID=113067049
|
|
|
|
|
|
|
| |
Fixes #643.
--
MOS_MIGRATED_REVID=113055336
|
|
|
|
|
|
|
|
| |
which is doing approximately the same thing dagger is doing, so is safe for the
same reasons.
--
MOS_MIGRATED_REVID=113054388
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=113052852
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is imperfect in many ways:
1) the value is opaque, and not a BUILD value, so it cannot be used
in rule arguments
2) its representation has a pointer address, so it breaks hermeticity.
Despite its problem, we return this value because otherwise
native.rules() fails if there is any rule using a select() in the
BUILD file.
A future solution would be to convert BuildType.SelectorList back to
syntax.SelectorList. To do so, we would have to
1) recurse into the Selector contents of SelectorList, so those values
are run through skylarkifyValue too
2) get the right Class<?> value. We could probably get at that by looking at
((SelectorList)val).getSelectors().first().getEntries().first().getClass().
--
MOS_MIGRATED_REVID=113051612
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
runfiles.
This is necessary because the plan for Windows calls for knowing if the target of the symlink is a directory or a file, thus, we cannot create runfiles trees before the artifacts in them are built. This probably comes with a performance hit due to the extra scheduling constraints.
This makes almost every test pass save:
- test_tmpdir in bazel_test_test, which I hereby dismiss as a fluke
- test_http_archive_tgz in external_integration_test (Maybe a permissions issue due to copying things?)
- A bunch of test in external_correctness_test, probably related to the fact that since we are copying things, we don't notice changes to the original files.
--
MOS_MIGRATED_REVID=113050025
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=113048962
|
|
|
|
|
|
|
| |
our plans for symlink support on Windows.
--
MOS_MIGRATED_REVID=113043269
|
|
|
|
|
|
|
|
|
|
|
| |
files itself, and one that contains this middleman and the runfiles output manifest.
This is in preparation for Windows symlink support in runfiles manifests: on Windows, we'll need the target files created before we can create the runfiles symlinks for them, but we can't do that by adding the current runfiles middleman to the inputs of SymlinkTreeAction because it would create a cycle (output manifest -> SymlinkTreeAction -> runfiles manifest -> MiddlemanAction -> output manifest)
The alternative is to just add the artifacts to the inputs of SymlinkTreeAction, but that would create a bunch of extra edges and, more importantly, reverse edges in the action graph which we don't want.
--
MOS_MIGRATED_REVID=113041344
|
|
|
|
|
|
|
| |
Stamping make build non-deterministic and should not be the default.
--
MOS_MIGRATED_REVID=113040937
|
|
|
|
|
|
|
|
|
|
|
|
| |
The consumers of Connect() function are just interested in knowning if
it has connected or not ("Did we connect?"). Leave the check for zero as
implementation detail of this function, making the callsites not having
to repeat the condition themselves.
--
Change-Id: Idc327c681c5defbb27039cd170f32d5ebd0e0a32
Reviewed-on: https://bazel-review.googlesource.com/#/c/2750/
MOS_MIGRATED_REVID=113040325
|
|
|
|
|
|
|
|
|
|
|
| |
for links to writable files.
Curiously enough, the native Unix JNI wrapper already had a function for link(), but it wasn't on the Java interface.
build-runfiles is also updated accordingly.
--
MOS_MIGRATED_REVID=113029168
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=112981819
|
|
|
|
|
|
|
| |
I thought Jekyll would translate these, but apparently not?
--
MOS_MIGRATED_REVID=112977415
|
|
|
|
|
|
|
|
| |
Apropos issue #776. This hint in the doc would have saved me from filing a bogus bug.
--
Reviewed-on: https://github.com/bazelbuild/bazel/pull/778
MOS_MIGRATED_REVID=112972220
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=112971086
|
|
|
|
|
|
|
|
| |
Update buildenv.sh to detect aarch64 as on Nvidias Jetson TX1 as ARM architecture. Final goal is to build tensorflow on jetson tx1
--
Reviewed-on: https://github.com/bazelbuild/bazel/pull/814
MOS_MIGRATED_REVID=112967980
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=112956748
|
|
|
|
|
|
|
|
|
|
| |
As it's about to get more important in its own right.
The only change that isn't just moving code around is making
RepositoryName.validate package-private.
--
MOS_MIGRATED_REVID=112956571
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=112952552
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Violates layering - genrule should not depend on platform- or language-specific parts.
*** Original change description ***
Add a DEVELOPER_DIR make variable to genrules to propagate the apple xcode environment variable DEVELOPER_DIR to commands.
If $(DEVELOPER_DIR) is included in the genrule command, we bootstrap the XCODE_VERSION_OVERRIDE environment variable to the command.
The contract with the actual action executor is, if XCODE_VERSION_OVERRIDE is present in the environment, to additionally bootstrap the DEVELOPER_DIR absolute path to the command.
--
MOS_MIGRATED_REVID=112951074
|
|
|
|
|
|
|
|
| |
Apparently, there's at least one case where errors are printed, but we exit
with a zero exit code. How's that.
--
MOS_MIGRATED_REVID=112950105
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=112948493
|
|
|
|
|
|
|
| |
initial step toward changing the manifest merge to use the Gradle merger, as well as ensuring the custom library package is reflected in the manifest.
--
MOS_MIGRATED_REVID=112943820
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also match ConfiguredTargetFunction for target loading.
It isn't currently possible to trigger either of these code paths
- the loading phase ensures that we never attempt to analyze targets that fail
to load
- the Skylark import or conversion cannot fail, because Skylark checks during
.bzl execution that all referenced symbols are Skylark aspects
Therefore, the only way to trigger this would be if there was a native rule
requesting a non-existent or broken Skylark aspect for its dependencies, but
that is currently not possible - native rules can only request native aspects.
However, for interleaved loading and analysis, we need to limit the set of
exception classes that can be thrown from AspectFunction - we do that here
by changing the constructor of AspectFunctionException to only accept either
NoSuchThingException or AspectCreationException.
That in turn requires that we re-throw the Skylark import and conversion
exceptions as AspectCreationException, which is exactly what
TopLevelAspectFunction is already doing, and necessary for correct error
handling if we do ever support Skylark aspects in native rules.
Alternatively, I could change the code path to crash Bazel, but that seems
strictly worse. Even if we can't test this code, it's conceptually the right
way to handle these errors.
I'll move part of the error handling into loadSkylarkAspect in a subsequent
change.
--
MOS_MIGRATED_REVID=112938284
|
|
|
|
|
|
|
|
|
| |
Bazel native rule inline documentation.
These variables are no longer used because the docgen templates now directly generate the table of attributes instead of using ATTRIBUTE_DEFINITION and call RuleDocumentation.getAttributeSignature() instead of using ATTRIBUTE_SIGNATURE. RuleDocumentation.getHtmlDocumentation() currently resolves both of these variables to the empty string.
--
MOS_MIGRATED_REVID=112933659
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=112931111
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main remaining problem with interleaved loading and analysis is error
handling. When interleaving, we don't run a real loading phase anymore, and
loading errors can occur during the analysis phase, and need to be handled
there.
The plan is to have ConfiguredTargetFunction throw a
ConfiguredValueCreationException with a list of all loading root causes, which
requires that we also catch ConfiguredValueCreationException here, which in
turn breaks analysis root cause handling, as that is currently relying on
Skyframe root cause tracking.
Moving analysis root cause handling into CTFunction makes it possible to
subsequently also implement loading root cause handling here. This is also
necessary if we want to have complete root cause handling in the general case:
a target may have any number (and combination) of loading and analysis root
causes at the same time.
For now, we only pass a single analysis root cause, which mirrors the current
Skyframe-based implementation.
--
MOS_MIGRATED_REVID=112930871
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note that this can never happen in production - the loading phase ensures that
we only attempt to analyze targets that load successfully. That's also why
there are no tests for this.
This code path will become live in a later change, with corresponding test
coverage; the existing tests cover this in principle, we just need to make
them run with the reduced loading phase.
--
MOS_MIGRATED_REVID=112926211
|
|
|
|
|
|
|
|
|
| |
a java_binary rule tries to find its main class when it doesn't have a
main_class attribute and that rule is defined in a parent directory of a
java/javatests directory.
--
MOS_MIGRATED_REVID=112851711
|
|
|
|
|
|
|
|
|
| |
specified.
If the build failure is caused by a catastrophic error, propagate the exit code from the catastrophe (EvaluationResult.getCatastrophe()) even when --keep_going.
--
MOS_MIGRATED_REVID=112845942
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
terminal, not the bazel server.
This fixes two user annoyances:
1) the command can now read from stdin
2) the bazel lock is not held when the command is invoked
The script use's bazel's `--script_path` flag to write out the shell script that runs the command.
--
MOS_MIGRATED_REVID=112815712
|
|
|
|
|
|
|
|
|
| |
action fails, and propagate the exit code to BuildFailedException.
And update all call sites that copy or wrap ActionExecutionExceptions.
--
MOS_MIGRATED_REVID=112811857
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=112790992
|
|
|
|
|
|
|
|
|
|
|
| |
pointing back to the main repository ("@//:...") work.
In principle, we should just use main repository labels instead of default repository labels in all the SkyKeys that take labels. @bsilver8192 is working on it, but in the meantime, this will serve to unblock @chin33z.
Fixes #811.
--
MOS_MIGRATED_REVID=112787545
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for targets in the transitive closure of a target that is built.
Previously, this would only happen if a link action for the library containing
the headers was also built; this specifically means it did not trigger if
a library didn't contain source files, as there is no link action for such
libraries. That led to no header-only libraries would get their headers parsed,
which includes all cc_public_library rules.
Adding a flag to introduce this under so we can switch it on independently from
the blaze release. Once it is switched on, we can remove the edges in the
action graph from the link actions to the header processing actions.
--
MOS_MIGRATED_REVID=112782219
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=112780859
|
|
|
|
|
|
|
|
|
|
| |
The generated XML output was incorrect.
See http://ci.bazel.io/job/Bazel/JAVA_VERSION=1.7,PLATFORM_NAME=ubuntu_15.10-x86_64/ws/bazel-testlogs/src/test/java/com/google/devtools/build/lib/shell_test/test.xml/*view*/
Fixes #812.
--
MOS_MIGRATED_REVID=112776671
|
|
|
|
|
|
|
|
|
|
| |
Currently, if an error occurs when cloning a git repository, resulting in a
GitAPIException being thrown, the error message printed is not very clear.
One example of this is if the repository is being cloned over SSH since cloning
over SSH is not currently supported.
--
MOS_MIGRATED_REVID=112770885
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently for a library:
cc_library(name='a', hdrs=['a.cc'])
we compile a.cc into a.pic.o and link that into its reverse dependencies.
With this change, a .cc file in hdrs will be treated like a .inc file or
a file in textual_hdrs.
--
MOS_MIGRATED_REVID=112770625
|