aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/tools/BUILD
Commit message (Collapse)AuthorAge
* Make Bazel build with MSVC-default-toolchain Bazel Gravatar Yun Peng2017-03-08
| | | | | | | | | | | | | After this change, a msys bazel can be built with a MSVC-default Bazel by adding --cpu=x64_windows_msys --host=x64_windows_msys See https://github.com/bazelbuild/bazel/issues/2627 -- Change-Id: Iaa82bf4dd911c5740b98d3b2739dfccca6203f79 Reviewed-on: https://cr.bazel.build/9293 PiperOrigin-RevId: 149532274 MOS_MIGRATED_REVID=149532274
* Bazel can now be built on Windows with MSVCGravatar Laszlo Csomor2017-01-31
| | | | | | | | | | | | | | | | | | | | | | | | bazel build //src:bazel --cpu=x64_windows_msvc now succeeds, hooray! This change adds empty implementations for build-runfiles and process-wrapper to make that possible. This means we can now build a bazel binary that doesn't depend on MSYS. The resulting binary is not yet functional because many methods are still to be implemented, and they just write "TODO: implement" or something similar. But still this is great news, because now we can add compile tests to the CI for MSVC! See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 146106178 MOS_MIGRATED_REVID=146106178
* Windows, native: add windows_msvc config_settingGravatar Laszlo Csomor2016-09-28
| | | | | | | | | | | | | | | Update `select` statements in BUILD files with the new config_setting. This is a first step on a long path that leads to us being able to compile bazel on Windows with --cpu=x64_windows_msvc. Needless to say, we're not there yet. Tested: on Linux, Darwin, Windows/MSYS -- MOS_MIGRATED_REVID=134534613
* Implement the first stage of Bazel's "Sandbox 2.0" for Linux.Gravatar Philipp Wollermann2016-08-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This has the following improvements upon the older one: - Uses PID namespaces, PR_SET_PDEATHSIG and a number of other tricks for further process isolation and 100% reliable killing of child processes. - Uses clone() instead of unshare() to work around a Linux kernel bug that made creating a sandbox unreliable. - Instead of mounting a hardcoded list of paths + whatever you add with --sandbox_add_path, this sandbox instead mounts all of /, except for what you make inaccessible via --sandbox_block_path. This should solve the majority of "Sandboxing breaks my build, because my compiler is installed in /opt or /usr/local" issues that users have seen. - Instead of doing magic with bind mounts, we create a separate execroot for each process containing symlinks to the input files. This is simpler and gives more predictable performance. - Actually makes everything except the working directory read-only (fixes #1364). This means that a running process can no longer accidentally modify your source code (yay!). - Prevents a number of additional "attacks" or leaks, like accidentally inheriting file handles from the parent. - Simpler command-line interface. - We can provide the same semantics in a Mac OS X sandbox, which will come in a separate code review from yueg@. It has the following caveats / known issues: - The "fallback to /bin/bash on error" feature is gone, but now that the sandbox mounts everything by default, the main use-case for this is no longer needed. The following improvements are planned: - Use a FUSE filesystem if possible for the new execroot, instead of creating symlinks. - Mount a base image instead of "/". FAQ: Q: Why is mounting all of "/" okay, doesn't this make the whole sandbox useless? A: This is still a reasonable behavior, because the sandbox never tried to isolate your build from the operating system it runs in. Instead it is supposed to protect your data from a test running "rm -rf $HOME" and to make it difficult / impossible for actions to use input files that are not declared dependencies. For even more isolation the sandbox will support mounting a base image as its root in a future version (similar to Docker images). Q: Let's say my process-specific execroot contains a symlink to an input file "good.h", can't the process just resolve the symlink, strip off the file name and then look around in the workspace? A: Yes. Unfortunately we could not find any way on Linux to make a file appear in a different directory with *all* of the semantics we would like. The options investigated were: 1) Copying input files, which is much too slow. 2) Hard linking input files, which is fast, but doesn't work cross- filesystems and it's also not possible to make them read-only. 3) Bind mounts, which don't scale once you're up in the thousands of input files (across all actions) - it seems like the kernel has some non-linear performance behavior when the mount table grows too much, resulting in the mount syscall taking more time the more mounts you have. 4) FUSE filesystem, good in theory, but wasn't ready for the first iteration. RELNOTES: New sandboxing implementation for Linux in which all actions run in a separate execroot that contains input files as symlinks back to the originals in the workspace. The running action now has read-write access to its execroot and /tmp only and can no longer write in arbitrary other places in the file system. -- Change-Id: Ic91386fc92f8eef727ed6d22e6bd0f357d145063 Reviewed-on: https://bazel-review.googlesource.com/#/c/4053 MOS_MIGRATED_REVID=130638204
* Rename namespace-sandbox/-runner to linux-sandbox.Gravatar Philipp Wollermann2016-07-18
| | | | | -- MOS_MIGRATED_REVID=127538990
* Move xcode-locator into src/tools packages, defining it as a target under ↵Gravatar Chris Parsons2016-05-30
| | | | | | | @bazel_tools. Currently the tool still remains in embedded_binaries, but we will migrate away from that: Eventually it can simply live just under @bazel_tools. -- MOS_MIGRATED_REVID=123436822
* Add a bazel-srcs target to the top-level package containing all Bazel sourcesGravatar Damien Martin-Guillerez2016-02-29
| | | | | | | | This target include all non tests targets of Bazel to do integration tests of bootstrapping. -- MOS_MIGRATED_REVID=115830741
* Introduce a special CPU for Windows and add msys compiler toolchain.Gravatar Dmitry Lomov2016-02-03
| | | | | | | | We might revisit what the default toolchain for Windows should be, but this CL uses msys to simplify bootstrapping. -- MOS_MIGRATED_REVID=113665255
* Add xcode_locator to bazel's embedded binaries.Gravatar Chris Parsons2016-01-08
| | | | | | | For bazel on non-darwin architectures, this will simply be a stub, and should never be invoked. On darwin arcitectures, the tool will map xcode version to xcode path on the host system. -- MOS_MIGRATED_REVID=111651147
* Upstream some basic changes from dslomov windows branch.Gravatar Dmitry Lomov2015-12-07
| | | | | | | | | The code changes are mostly due to dslomov, not me, although I refactored the Jvm class a bit based on his changes. I set dslomov as the author. -- Reviewed-on: https://github.com/bazelbuild/bazel/pull/688 MOS_MIGRATED_REVID=109536553
* handle darwin_x86_64 target cpuGravatar Chris Parsons2015-10-30
| | | | | -- MOS_MIGRATED_REVID=106605250
* Introduce two new options to Linux sandbox wrapper:Gravatar Ming Zhao2015-10-08
| | | | | | | | | | | * -n: Create a new network namespace with only loopback interface. * -r: set the uid/gid inside the sandbox to be root (instead of nobody) so that setuid programs like ping can still run when needed. -- Change-Id: I8ab434e47e0f6933ee9de02e135c8daec39fe73f Reviewed-on: https://bazel-review.googlesource.com/#/c/2101/ MOS_MIGRATED_REVID=104858163
* Port to FreeBSD.Gravatar Doug Rabson2015-08-26
| | | | | | | -- Change-Id: I4e65cc583e758d2f7e45209ffcb37f6a871e2ed7 Reviewed-on: https://bazel-review.git.corp.google.com/#/c/1840 MOS_MIGRATED_REVID=101462155
* Execute spawns inside sandboxes to improve hermeticity (spawns can no longer ↵Gravatar Philipp Wollermann2015-08-26
| | | | | | | | | | | | use non-declared inputs) and safety (spawns can no longer affect the host system, e.g. accidentally wipe your home directory). This implementation works on Linux only and uses Linux containers ("namespaces"). The strategy works with all actions that Bazel supports (C++ / Java compilation, genrules, test execution, Skylark-based rules, ...) and in tests, Bazel could successfully bootstrap itself and pass the whole test suite using sandboxed execution. This is not the default behavior yet, but can be activated explicitly by using: bazel build --genrule_strategy=sandboxed --spawn_strategy=sandboxed //my:stuff -- MOS_MIGRATED_REVID=101457297
* Get jdk.WORKSPACE into the default WORKSPACE file by reading it as a Java ↵Gravatar Lukacs Berki2015-06-15
| | | | | | | | | | | resource, then passing it to the parser as a string instead of putting it into embedded_binaries then passing a Path to it to the parser. This makes the upcoming default WORKSPACE rules for Android much more palatable. In particular, Android rules won't need to be special cased when building the Bazel binary because the contents are self-contained in BazelRuleClassProvider (and the jdk.WORKSPACE file, which is a simple Java resource) Even better would be not to use a string, but some kind of structured data, but that's probably more effort than it's worth. -- MOS_MIGRATED_REVID=95983199
* Make JDK not need tools/jdk/jdk symlinkedGravatar Kristina Chodorow2015-03-18
| | | | | -- MOS_MIGRATED_REVID=88742425
* Make Rule know about the name of the workspace it is in.Gravatar Kristina Chodorow2015-03-05
| | | | | | | This is needed for taking the runfiles prefix from the WORKSPACE file instead of hardcoding it. -- MOS_MIGRATED_REVID=87347883
* Update from Google.Gravatar Han-Wen Nienhuys2015-02-25
-- MOE_MIGRATED_REVID=85702957