commit | 22513330de1212d05c2342d4290a057b214a9b96 | [log] [tgz] |
---|---|---|
author | Francois-Rene Rideau <tunes@google.com> | Fri Feb 27 15:20:29 2015 +0000 |
committer | Han-Wen Nienhuys <hanwen@google.com> | Wed Mar 04 15:39:03 2015 +0000 |
tree | aec87019f248547e996826f542aca5df14ab31c6 | |
parent | 72ca13d9c90f2c40ffe0c82e24d2f99289f851ce [diff] |
Add Union, contains() to SkylarkType Refactor SkylarkType, notably adding Union types and runtime typechecks. These are pre-requisites to unifying all Skylark function calls to use the same code path, that will check types (like SkylarkFunction currently does) as well handle a more complete Python calling convention (like MixedModeFunction is almost but not quite able to do). A SkylarkType can be either * a Simple type corresponding to a Java class, with special types TOP and BOTTOM corresponding respectively to Object and EmptyType (similar to Void). * a Combination of a generic class (LIST, MAP or SET) and an argument type * a Union of a finite number of types * a FunctionType associated with a name and a returnType (with ugly validation-time side-effects that we should probably move out of the type) Unions are necessary because: 1- the type of some builtin function arguments are actually the Union of some type and a function type for a callback that computes the actual value. 2- the type of some builtin function arguments declared as "List" is actually the Union of java List and SkylarkList. 3- instead of adding lots of special cases at the point of argument validation, it's cleaner and more generally useful to have explicit Union types, that can then be displayed to users for documentation or debugging purposes. Validation-time "type inference" is re-expressed simply as type intersection. None is treated specially as inferred into TOP instead of NoneType. Combination types are printed as genericType of argTypes, e.g. "dict of ints". "type" and "generic1" become "genericType" and "argType". In SkylarkList and SkylarkNestedSet, genericType becomes contentType. -- MOS_MIGRATED_REVID=87340881
Bazel is very much a work in progress. We'd love if you tried it out, but there are many rough edges. Please feel free to give us feedback!
{Fast, Correct} - Choose two
Bazel is an build tool that builds code quickly and reliably. It executes as few build steps as possible by tracking dependencies and outputs, controls the build environment to keep builds hermetic, and uses its knowledge of dependencies to parallelize builds.
This README file contains instructions for building and running Bazel.
Supported platforms:
Java:
Clone the Bazel repo from GitHub:
$ cd $HOME $ git clone https://github.com/google/bazel/
To build Bazel on Ubuntu:
Install required package:
$ sudo apt-get install libarchive-dev
Build Bazel:
$ cd bazel $ ./compile.sh
Using Bazel on Mac OS X requires:
To build Bazel on Mac OS X:
Install required packages:
$ port install protobuf-cpp libarchive
or
$ brew install protobuf libarchive
Build Bazel:
$ cd bazel $ ./compile.sh
The Bazel executable is located at <bazel_home>/output/bazel
.
You must run Bazel from within a workspace directory. Bazel provides a default workspace directory with sample BUILD
files and source code in <bazel_home>/base_workspace
. The default workspace contains files and directories that must be present in order for Bazel to work. If you want to build from source outside the default workspace directory, copy the entire base_workspace
directory to the new location before adding your BUILD
and source files.
Build a sample Java application:
$ cp -R $HOME/bazel/base_workspace $HOME/my_workspace $ cd $HOME/my_workspace $ $HOME/bazel/output/bazel build //examples/java:hello-world
Note: on OS X, you must specify --cpu=darwin to build Java programs (e.g., bazel build --cpu=darwin //examples/java:hello-world).
The build output is located in $HOME/my_workspace/bazel-bin/examples/java/
.
Run the sample application:
$ $HOME/my_workspace/bazel-bin/examples/java/hello-world