* Set execute bit on files if and only if they begin with (#!).
Git only tracks the 'x' (executable) bit on each file. Prior to this
CL, our files were a random mix of executable and non-executable.
This change imposes some order by making files executable if and only
if they have shebang (#!) lines at the beginning.
We don't have any executable binaries checked into the repo, so
we shouldn't need to worry about that case.
* Added fix_permissions.sh script to set +x iff a file begins with (#!).
* [bazel] Move Java runtime/toolchains into //java
This change moves `java_library` targets from the top-level BUILD file
into `//java/{core,lite,util}` and declares `alias` targets to point to
their new locations (hence, this is not a breaking change).
This will allow users that don't use Java to stop depending on
`@rules_java` (e.g. as requested in
https://github.com/bazelbuild/rules_scala/pull/989#issuecomment-583405161).
Note that there is no intention to deprecate + remove the top-level
targets in the foreseeable future.
* Add BUILD files in //java to java_EXTRA_DIST
This change adds the required loads to examples and zlib.
For full compatibility with --incompatible_load_{cc,java,proto}_rules_from_bzl,
we will need to roll gtest to a newer version.
To make this work, I created a symlink to the existing zlib.BUILD file.
Maybe there is a better way to do this, but this is at least a quick
workaround to fix the build.
@bazel_skylib//:lib is supposedly deprecated. The 'versions' struct in lib.bzl was committed to bazel-skylib at the same time as //lib:versions.bzl, so there should be no backward incompatibility.
The example utilizes native bazel rules (proto_library, cc_proto_library,
java_proto_library, java_lite_proto_library) to show how easy it is to
build protobuf with bazel's native support. It also makes use of well
known types which was not possible until the latest bazel 0.5.4 release
and https://github.com/google/protobuf/pull/3594 .
A series of improvements:
- Improved Protobuf module compatibility (disabled by default);
- Hide advanced settings;
- Added build tree configuration;
- Added build of examples.
This will allow us to like to specific snippets of code in the
documentation. I plan to create a tutorial similar to the C# tutorial
https://developers.google.com/protocol-buffers/docs/csharptutorial
Since that tutorial has sections for populating a proto, parsing, and
serializing, I made a region for each of these for Go. To make the
populating sample more self-contained, I refactor the listing example
slightly.
Since these tags might be confusing, added a note that these are not
part of the normal protocol buffers syntax. I also linked to the main
tutorials page that uses these examples
https://developers.google.com/protocol-buffers/docs/tutorials so that
anyone who arrived here without going through that info first can get
more explanation if they want.
This follows the other examples so that it can be used as a tutorial,
such as the ones at:
https://developers.google.com/protocol-buffers/docs/tutorials
Even though Go generally does not use Makefiles, I added targets for the
Go examples to be consistent with the other languages.
Edit:
Fix Travis run. Change to use $HOME instead of ~. Add protoc to path.
GOPATH entry cannot start with shell metacharacter '~': "~/gocode"
Edit(2):
Fix Go code style to address comments.
To my surprise, executing generate_protos.sh used the version of Bash installed with Git for Windows by default.
After a few modifications to detect the most appropriate protoc to use, this worked pretty simply.
This change also:
- adds generation of the address book tutorial proto,
- fixes the addressbook.proto to specify proto2 explicitly (to avoid a warning from protoc; I don't think we want warnings...)
- fixes the addressbook.proto C# namespace (which I thought I'd done before, but apparently hadn't)
- includes the regenerated UnittestCustomOptions.cs apart from the DescriptorProtoFIle => Descriptor change
