aboutsummaryrefslogtreecommitdiffhomepage
path: root/scripts/bootstrap/bootstrap.sh
Commit message (Collapse)AuthorAge
* SOURCE_DATE_EPOCH environment variable override the timestampGravatar Damien Martin-Guillerez2017-11-21
| | | | | | | | | | | | | | | | | | | | This is applying the version 1.1 of the specification (https://reproducible-builds.org/specs/source-date-epoch/) where the only timestamp that Bazel puts in the final targets is overridden by the value of SOURCE_DATE_EPOCH. This change also remove the legacy SOURCE_DATE_EPOCH handling which wasn't really following the spec. Note that Bazel itself tries hard to remove all timestamps from intermediary binaries and overridde SOURCE_DATE_EPOCH in most action, which is a not according to the version 1.0 of the spec but according to the expected change for version 1.1. RELNOTES: SOURCE_DATE_EPOCH (https://reproducible-builds.org/specs/source-date-epoch/) can be used to override the timestamp used for stamped target (when using --stamp). Fixes #2240. Change-Id: I074e7905fa6745cc706f7391340aeae9188909ca PiperOrigin-RevId: 176489717
* Remove support for --javabase=<absolute path>.Gravatar lberki2017-10-11
| | | | | | | | | | | | | | | | | | | | | | If an absolute javabase is desired, the following set of rules can be used: java_runtime_suite(name="suite", default=":runtime") java_runtime(name="runtime", java_home=<path to the JDK>) Then --javabase can be pointed to the java_runtime_suite() rule. Alternatively, the java_runtime rule can reference a Make variable: java_runtime(name="runtime", java_home="$(ABSOLUTE_JAVABASE)") Then the Javabase can be specified on the command line like this: --javabase=<your package>:suite --define=ABSOLUTE_JAVABASE=<path to the JDK> RELNOTES[INC]: --javabase=<absolute path> and --host_javabase=<absolute path> are not supported anymore. If you need this functionality java_runtime_suite(name="suite", default=":runtime") java_runtime(name="runtime", java_home=<path to the JDK>) is an alternative. PiperOrigin-RevId: 171798416
* Add a Bazel test testing determinism of `bazel build //src:bazel`Gravatar Damien Martin-Guillerez2017-08-23
| | | | | | | | | - Test if hash(bazel1) == hash(bazel2) This ensure that the build of bazel is a fixed point. Change-Id: I422dfc7ec5b95aa054a2677e59427cbd8cd4ef01 PiperOrigin-RevId: 166180529
* Windows, bootstrapping: fix bugs to support CygwinGravatar Laszlo Csomor2017-04-26
| | | | | | | | | | | | | | | | | | | | | | | | | | We can't yet fully bootstrap Bazel on Cygwin, but can build Bazel from scratch. Building Bazel with Bazel fails because gcc isn't found where it's believed to be -- /usr/bin is a mount in Cygwin (to /bin), not a symlink or directory. In this change I: - added support for the Cygwin shell as a bootstrap platform (recognize `uname`) - updateed the bootstrap scripts to use "windows" as the PLATFORM string, not "mingw" - fixed the git lookup code - removed some hardwired msys-style path - added a cygpath call to convert $PWD to a mixed-style (otherwise the bootstrap script passes --client_cwd=/cygdrive/c/... to the server and WindowsFileSystem.java wants to make that relative to c:/cygwin64) See https://github.com/bazelbuild/bazel/issues/2885 Change-Id: Icc71261ea4f0c6d4a9c0846551a7977ca6020331 PiperOrigin-RevId: 154273014
* Honor SOURCE_DATE_EPOCH in bootstrapping Gravatar Klaus Aehlig2017-03-23
| | | | | | | | | | | | | | | | | | | | | | | | | | Currently, a stamped bazel binary contains the actual timestamp at build time. This means, that building bazel we either include no version information at all, or the binary contains a not reproducible time stamp. Both are not acceptable from the point of view of a downstream maintainer of a bazel package, where the requirement is that the package be reproducible, but the binary still provide sensible version information. Fortunately, there is a suggested standard to solve this problem taking the "current time" from the SOURCE_DATE_EPOCH environment variable, if set, rather than the actual time. See https://reproducible-builds.org/specs/source-date-epoch/. Honor this proposed standard, so that bazel can reasonably be packaged downstream. See issue #2240. Note that we only use the environment variable in our bootstrap script; for bazel itself we communicate that information via an appropriate option. -- Change-Id: I55409a117285b9a3446421179c20f4e8c59088f8 Reviewed-on: https://cr.bazel.build/9467 PiperOrigin-RevId: 150896326 MOS_MIGRATED_REVID=150896326
* Windows: fix bootstrapping bugs with 0.4.4 Gravatar László Csomor2017-02-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix 3 bugs to get bootstrapping working on Windows after it was broken in bazel-0.4.4: * Move the definition of PATHSEP to before the code that overrides it for Windows * Fix the Java code processing the --javahome flag to recognize absolute Windows paths as absolute. See: https://github.com/bazelbuild/bazel/issues/2520 * Do not propagate the JAVA_HOME value in variables, because it contains spaces on Windows, and when we pass the variable to Bazel, and it's expanded to e.g. ... --foo=C:/Program Files, these are interpreted as two args instead of one. Also fix a bug that is just annoying, not causing any trouble (on Windows): * Silently swallow errors from the "rm -rf" in the atexit functions Also do some refactoring: * Rename a variable (BAZEL_ARGS) and a method to indicate they're private. They are not used from anywhere else as far as I know -- no occurrences in either the bazel or the continuous-integration repos. Fixes: https://github.com/bazelbuild/bazel/issues/2473 -- Change-Id: I309752cd7bbff0b5dd683ddb5573f3061350043c Reviewed-on: https://cr.bazel.build/8797 PiperOrigin-RevId: 147345194 MOS_MIGRATED_REVID=147345194
* Fix bootstrapping in Docker images.Gravatar Lukacs Berki2017-01-20
| | | | | | | | | | | | | | | | | | Turns out, we couldn't run jarjar because the Java launcher script looks for the .jars in the runfiles and build-runfiles is stubbed out during bootstrapping. The only reason why this worked at all is that sandboxing *also* doesn't work during bootstrapping but it causes the creation of symlinks that happened to be just in the right place for the Java launcher to find the .jars . The fix is: - Explicitly disable sandboxing during bootstrapping so that coincidences like this don't happen again - Pass a --javabase and --host_javabase option during the bootstrap build so that we don't need any symlinks to access to JVM - Invoke jarjar using its deploy jar instead of the launcher script. That was fun. -- PiperOrigin-RevId: 145083357 MOS_MIGRATED_REVID=145083357
* Disable turbine for bootstrap buildsGravatar Liam Miller-Cushon2017-01-12
| | | | | | -- PiperOrigin-RevId: 144296949 MOS_MIGRATED_REVID=144296949
* Bootstrapping: don't use convenience symlinksGravatar Laszlo Csomor2016-09-27
| | | | | | | | | | | | | | | | | | | | | | When `compile.sh` builds bazel using bazel, it copies the resulting binary to `output/bazel`. However sometimes the convenience symlink `bazel-bin` is not created, probably because an old one is still around and cannot be deleted. That is clearly a bug, but to work around it, the bootstrap builder shouldn't attempt to rely on the creation of these symlinks in the first place. This change updates compile.sh to use `bazel info` to locate the `bazel-bin` directory's real path, and attempt to copy the bazel binary from there. This works around https://github.com/bazelbuild/bazel/issues/1827 -- MOS_MIGRATED_REVID=134398451
* Bazel bootstrapping: build an optimized binaryGravatar Laszlo Csomor2016-09-26
| | | | | | | | | Pass "-c opt" when building bazel. Fixes https://github.com/bazelbuild/bazel/issues/1830 -- MOS_MIGRATED_REVID=134307054
* Let Bazel use sandboxing during bootstrap, if it's available.Gravatar Philipp Wollermann2016-08-17
| | | | | -- MOS_MIGRATED_REVID=130406085
* Bootstrap Bazel with debug symbols.Gravatar Philipp Wollermann2016-07-15
| | | | | | | This helps a lot when trying to debug Bazel from an IDE. -- MOS_MIGRATED_REVID=127529499
* Make bootstrapping support a designated work dirGravatar Klaus Aehlig2016-07-11
| | | | | | | | | | | | | Change the bootstrapping process so that setting the BAZEL_WRKDIR environment variable will tell the bootstrap process to mostly write to that directory---apart from adding the symlinks next to the WORKSPACE file. So setting this variable will avoid the usual writes to random places in the file system (like /tmp and the user's home directory). -- Change-Id: I9d1af747e75cc2a7bb1af08308acc9dfd927e920 Reviewed-on: https://bazel-review.googlesource.com/#/c/3963 MOS_MIGRATED_REVID=127075535
* Wire up --host_java_toolchainGravatar Liam Miller-Cushon2016-04-22
| | | | | -- MOS_MIGRATED_REVID=120574676
* Fix Bazel JDK 7 buildGravatar Damien Martin-Guillerez2016-04-21
| | | | | | | | Once and for all, I tested it and re-tested should be good. -- MOS_MIGRATED_REVID=120381352
* Refactor JDK 7 build to use the vendored version of itGravatar Damien Martin-Guillerez2016-04-20
| | | | | | | | | | | | | Along the path, fix the build for JDK 7 and get rid of most ugliness in the JDK 7 build. Now simply setting JAVA_VERSION to 1.7 will build a JDK 7 compatible version. Fixes #1159. -- Change-Id: I9599283844a57d9e053f12d37445907f22a9232e Reviewed-on: https://bazel-review.googlesource.com/#/c/3452 MOS_MIGRATED_REVID=120332747
* Deprecate top-level Java toolchain flags in favour of java_toolchainGravatar Liam Miller-Cushon2016-04-19
| | | | | | | | | | | | | This change disables --java_langtools, --javabuilder_top, --singlejar_top, --genclass_top, and --ijar_top, and finishes replacing them with java_toolchain.{javac,javabuilder,singlejar,genclass,ijar}. RELNOTES: Replace --java_langtools, --javabuilder_top, --singlejar_top, --genclass_top, and --ijar_top with java_toolchain.{javac,javabuilder,singlejar,genclass,ijar} -- MOS_MIGRATED_REVID=120154954
* Rollback of commit 6cb8d820689ad029a9d0dc4ee1100db9b2d96515.Gravatar Damien Martin-Guillerez2016-04-14
| | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Breaks ci.bazel.io While the basics for fixing the build is easy (just a few typos in packages building), fixing the test is a bit more tricky. I see only one solution for fixing the test: use a select statement that would select the good bazel version but that would always pull JavaBuilder as an external dependency when we do test. Better roll this back then check the JavaBuilder 0.1.0 as a binary in third_party before rolling forward (a similar change is still needed to decouple running the test and building the binary for JDK 7) *** Original change description *** Refactor build for JDK 7 Now the JDK 7 tuning happens all in Bazel, removing logic from the CI script. It uses remote repositories to access JDK 7 dependencies. -- MOS_MIGRATED_REVID=119773123
* Refactor build for JDK 7Gravatar Damien Martin-Guillerez2016-04-13
| | | | | | | | | | | Now the JDK 7 tuning happens all in Bazel, removing logic from the CI script. It uses remote repositories to access JDK 7 dependencies. -- Change-Id: Iff590c6642ca5b2343aa15096f8fd837d1c80787 Reviewed-on: https://bazel-review.googlesource.com/#/c/3327 MOS_MIGRATED_REVID=119634530
* Allow outputting the progress of Bazel's build.Gravatar Julio Merino2016-02-26
| | | | | | | | | | | | Rename run_silent to run and add a global VERBOSE variable that tunes whether the run function prints its output or not. This is for better debugging possibilities of Bazel's self-build, though compile.sh remains silent as before and only displays the command's output in case of an error. -- MOS_MIGRATED_REVID=115599355
* Use label syntax that is immune to MSYS path mangling in bootstrap scripts.Gravatar Dmitry Lomov2016-01-29
| | | | | | | | | | | On Windows, MSYS will mangle all arguments that resemble Unix paths when executing (exec*()) non-msys executables (in an attempt to convert them to Windows paths). This affects ``//src:bazel`` (it becomes ``/src:bazel``) but not ``src:bazel``. This CL converts to the latter in bootstrapping shell scripts to work around this issue. -- MOS_MIGRATED_REVID=113349821
* Fix Bazel bootstrapping with JDK 7Gravatar Damien Martin-Guillerez2016-01-18
| | | | | | | | | | | With latest change to the bootstrap compilation, some options were wrongly moved around. Tested with `source scripts/ci/build.sh; bazel_build` for JAVA_VERSION 1.7 and 1.8. -- MOS_MIGRATED_REVID=112409496
* Use only the Bazel server for bootstrappingGravatar Damien Martin-Guillerez2016-01-18
| | | | | | | This remove all C++ compilation in bootstrapping itself. -- MOS_MIGRATED_REVID=112407516
* Inline bazel_bootstrap in compile.shGravatar Damien Martin-Guillerez2016-01-18
| | | | | | | This method is used only once now so inline. -- MOS_MIGRATED_REVID=112396086
* Do not use sandboxing when bootstrappingGravatar Damien Martin-Guillerez2016-01-18
| | | | | | | | This simplify the bootstrap process and remove a C++ tool from the bootstrap binary. -- MOS_MIGRATED_REVID=112394555
* Fix bazel args in the bootstrap testGravatar Damien Martin-Guillerez2016-01-15
| | | | | -- MOS_MIGRATED_REVID=112239696
* Rollback of commit ac6ed79e1a3fa6b0ca91657b28e2a35f7e49758c.Gravatar Damien Martin-Guillerez2016-01-11
| | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Roll-forward with fix *** Original change description *** Automated [] rollback of []. *** Reason for rollback *** Broke tests on Mac: https://google.com/url?sa=D&q=http%3A%2F%2Fci.bazel.io%2Fjob%2FBazel%2FJAVA_VERSION%3D1.8%2CPLATFORM_NAME%3Ddarwin-x86_64%2F269%2Fconsole *** Original change description *** Speed-up bootstrap on OS X by removing tool compilation. -- MOS_MIGRATED_REVID=111833617
* Rollback of commit b9f401b97590cb95e76efb0ba8bf5319cfe93108.Gravatar Dmitry Lomov2015-12-22
| | | | | | | | | | | | | *** Reason for rollback *** Broke tests on Mac: https://google.com/url?sa=D&q=http%3A%2F%2Fci.bazel.io%2Fjob%2FBazel%2FJAVA_VERSION%3D1.8%2CPLATFORM_NAME%3Ddarwin-x86_64%2F269%2Fconsole *** Original change description *** Speed-up bootstrap on OS X by removing tool compilation. -- MOS_MIGRATED_REVID=110785493
* Speed-up bootstrap on OS X by removing tool compilation.Gravatar Damien Martin-Guillerez2015-12-21
| | | | | -- MOS_MIGRATED_REVID=110704529
* Allow specification of bazel target for bootstrap.Gravatar Peter Schmitt2015-11-24
| | | | | -- MOS_MIGRATED_REVID=108500888
* Enable the worker strategy for Javac in Bazel during bootstrap.Gravatar Philipp Wollermann2015-11-05
| | | | | | | Bazel builds 4x faster than before, which also speeds up CI and running the test suite. -- MOS_MIGRATED_REVID=107067655
* Make the bootstrapping process work again after moving tools to the ↵Gravatar Lukacs Berki2015-10-12
| | | | | | | | | | | @bazel_tools repository. The fix is to always compile tools when the Bazel binary is compiled and add the bootstrap arguments to bootstrap_test. This stil litters the git client with output files in random places, which is a bit difficult to fix, since //src:bazel expects these files to be there so that it can embed them into the output binary. I didn't notice this issue because tools/jdk/*_deploy.jar is in the .gitignore file, thus, when "git status" reported nothing, I asumed I ran the build in a clean client. -- MOS_MIGRATED_REVID=105206124
* Fix our Java 7 buildGravatar Damien Martin-Guillerez2015-10-02
| | | | | | | | | | | | | | | | | | - Follow redirects when downloading files: The github provided file lies after several redirect, giving a bad jars (see http://ci.bazel.io/job/Bazel/JAVA_VERSION=1.7,PLATFORM_NAME=linux-x86_64/144/console). - Remove building tools as part of the determinism tests: With recent update, JavaBuilder can no longer be built with Java 7, so we use a pre-built binary from version 0.1.0. However, the determinism test was still using it as a point of comparison. Removing tools from the determinism test prevent building JavaBuilder without giving up on testing actual determinism (building Bazel already contains all the edge-cases). Tested with `bash -c 'export JAVA_VERSION=1.7; source scripts/ci/build.sh; bazel_build'` -- MOS_MIGRATED_REVID=104480161
* Rationalize copyright headersGravatar Damien Martin-Guillerez2015-09-25
| | | | | | | | | | | 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
* Adds gen jar and manifest proto outputs.Gravatar Alex Humesky2015-07-10
| | | | | | | Adds a jar output to Java and Android rules which contains the class files for source files generated from Java annotation processors. For a java_binary foo, the jar will be foo-gen.jar, and for a java_library foo the jar will be libfoo-gen.jar, and similarly for Android. Also adds a binary serialized proto manifest file output to Java and Android rules which describes the contents of the output class jar of those rules, which is used to create the -gen.jar. See src/main/protobuf/java_compilation.proto. -- MOS_MIGRATED_REVID=97793715
* Support the --[no]master_bazelrc flagGravatar Damien Martin-Guillerez2015-06-25
| | | | | | | And get rid of usage of "blazerc" flags in our scripts. -- MOS_MIGRATED_REVID=96776423
* Use --expunge to bazel clean for the deterministic testGravatar Damien Martin-Guillerez2015-06-19
| | | | | | | | | When doing the deterministic test on Bazel, some output files of previous compilation where still there and the result of the compilation wouldn't be perfect. -- MOS_MIGRATED_REVID=96396183
* Added /etc/bazel.bazelrc as a global Bazel's master rc.Gravatar Damien Martin-Guillerez2015-06-15
| | | | | | | | | | This will allow system-wide configuration for system-wide installation of Bazel. -- Change-Id: I71b7232e648f2690766c3b9184f863dc888524c0 Reviewed-on: https://bazel-review.googlesource.com/#/c/1540/ MOS_MIGRATED_REVID=95994630
* Reorganized compile.shGravatar Damien Martin-Guillerez2015-06-10
Now the blessed Bazel binary is self-hosted and correctly labeled. All tools are also built using Bazel and labeled with the release. At the end of the compilation, the output folder only host the Bazel binary now. We use temporary folders to store the intermediate artifacts. Also integrated ./bootstrap_test.sh in compile.sh so there is only one script for everything regarding bootstraping Bazel. -- Change-Id: Idadbd075e7b8ecb6e306b919b7a73c647c5cfbae Reviewed-on: https://bazel-review.googlesource.com/#/c/1460/ MOS_MIGRATED_REVID=95625880
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-31 12:08:15 +0000