Created attachment 163079 [details] shar archive This is Google's newly released build system (brother of configure, make, cmake, ant, etc). This port builds and works, however it depends on yet unreleased devel/protobuf version v3.0.0-alpha-3 (last released version is 2.6.1). I requested bazel developers to either include non-standard version into their build, or switch to the last released version. Once they do this, I will update this bug report and label it "ready". It doesn't look like bazel is a great build system. It is badly bloated, depends on Java, and suffers from some shortcomings. But I already spotted several projects that depend on bazel for their build. So it is important to have it in FreeBSD to unblock such ports. So this is pending bug for now.
@Yuri please create a blocking issue for the protobuf update (if you haven't already). That will be enough to mark this as not ready to land, as it will be pending a changeset and commit before this one can move
Created attachment 163106 [details] shar archive All fixed. Passes poudriere. Now the port is ready.
Created attachment 163107 [details] poudriere log Please note that bazel executable has to remain unstripped (because it contains a giant zip archive in it). So this warning should be waived: $ Warning: 'bin/bazel' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD}
Note that whilst this port builds and installs, I can't get it to actually work. Trying the first example at http://bazel.io/docs/getting-started.html, I get: server% rm -fr ~/.cache server% ls -lR total 26 -rw-r--r-- 1 peter wheel 117 22 Nov 16:31 BUILD -rw-r--r-- 1 peter wheel 0 22 Nov 16:31 WORKSPACE drwxr-xr-x 3 peter wheel 3 22 Nov 16:30 src ./src: total 17 drwxr-xr-x 3 peter wheel 3 22 Nov 16:30 main ./src/main: total 17 drwxr-xr-x 3 peter wheel 3 22 Nov 16:30 java ./src/main/java: total 17 drwxr-xr-x 3 peter wheel 3 22 Nov 16:30 com ./src/main/java/com: total 17 drwxr-xr-x 2 peter wheel 4 22 Nov 16:30 example ./src/main/java/com/example: total 17 -rw-r--r-- 1 peter wheel 122 22 Nov 16:30 Greeting.java -rw-r--r-- 1 peter wheel 130 22 Nov 16:30 ProjectRunner.java server% bazel build //:my-runner Extracting Bazel installation... ....... ERROR: Loading of target '//tools/cpp:toolchain' failed; build aborted: no such package 'tools/cpp': BUILD file not found on package path. ERROR: Loading failed; build aborted. INFO: Elapsed time: 1.628s There is a //tools/cpp in ${WRKSRC} and it winds up unpacked in ~/.cache/bazel/_bazel_peter/install/74224bf095e5083be582f54ee1273ae7/_embedded_binaries/android_tools/tools A ktrace shows that cpp/BUILD relative to both that directory and ./tools is checked (with lstat(2)) but the absence of the latter path appears to trigger the error message. I'm still trying to work out what the correct fix is.
This needs to be put on hold. It works, but it is missing libs of standard rules as I also found out. Like this one //tools/cpp:toolchain. I will do this in a week.
They have tools/ directory with all required and random stuff mixed. They couldn't tell themselves what is required and what isn't, and I didn't feel like dropping the whole directory into the port, like Arch does. So it will take few hours to sort out. Will update by next Sunday.
I've done some more poking around and compared the proposed port with bazel-0.1.1-installer-linux-x86_64.sh. The latter installs a smaller bazel but separately installs a large collection of files in /usr/local/lib/bazel/base_workspace/ and appends that path to --package_path. I suspect this is the correct approach. I have verified that adding ${WRKSRC} to --package_path make bazel work. Having looker closer at the Makefile, I notice a couple of issues that should be looked into: - There's a test suite in bazel and it would be useful if that was hooked into "make test" - ${REINPLACE_CMD} includes the '-i' option. Also '-i' takes an option so the Makefile winds up using '-e' as a suffix for backup files. - do-build deletes files in ${HOME}. This is highly undesirable - the Makefile should override ${HOME} so that the port does not alter any files outside ${WRKDIR} - There are many occurrences of /bin/bash and md5sum that are not corrected. This definitely causes test failures but it's not clear whether it would impact normal bazel operation.
It would take some time to sort out what bazel really requires. Obviously port doesn't need things like this: > %%DATADIR%%/third_party/java/buck-ios-support/java/com/facebook/buck/apple/xcode/xcodeproj/PBXObject.java I will update once all details are settled. In the mean time, if you just need to run bazel, current executable works. You need to create ~/.bazelrc with such lines: build --package_path %workspace%:/usr/ports/devel/bazel/work/bazel-0.1.1/base_workspace fetch --package_path %workspace%:/usr/ports/devel/bazel/work/bazel-0.1.1/base_workspace query --package_path %workspace%:/usr/ports/devel/bazel/work/bazel-0.1.1/base_workspace Test case you mentioned passes fine. Just the matter of these files being there.
https://github.com/bazelbuild/bazel/issues/658
The previous issue (with dependencies) is closed. But now the build hangs on FreeBSD for bazel-0.2.2b: https://github.com/bazelbuild/bazel/issues/1250 Pending their response.
Created attachment 170220 [details] shar archive All problems have been sorted out in the latest version 0.2.2b. Passes poudriere on 10.3.
Bazel compile currently fails on 9.3. This is caused by the different behavior of the same version of clang on different versions of OS. I added the blocking bug.
Created attachment 170233 [details] shar archive Unblocked, marked broken only on FreeBSD 9. ---- ready to commit ----
testbuilds@work
(In reply to yuri from comment #13) Building on 11a on a loaded host says: Error: /usr/local/bin/bazel is linked to /usr/local/lib/libc++.so.1 from devel/libc++ but it is not declared as a dependency Warning: you need LIB_DEPENDS+=libc++.so:devel/libc++ Is this valid ?
It fails on 10.3-i386: src/main/native/unix_jni.cc:867:7: error: no matching function for call to 'portable_sysctlbyname' if (portable_sysctlbyname(name_chars, &r, &len) == -1) { ^~~~~~~~~~~~~~~~~~~~~ ./src/main/native/unix_jni.h:95:5: note: candidate function not viable: no known conversion from 'jlong *' (aka 'long long *') to 'long *' for 2nd argument int portable_sysctlbyname(const char *name_chars, long *mibp, size_t *sizep); ^ 1 error generated. Target //src:bazel failed to build Should it work on i386 ?
Okay, I will look at 11 and 10.3 i386 cases. I only built it on 10.3 amd64 myself.
The current status is that the latest version 0.4.0 hangs on FreeBSD: https://github.com/bazelbuild/bazel/issues/1250 Due to the likely bug in JDK build hangs. No known workaround.
Created attachment 176856 [details] shar of bazel-0.4.0 that hangs
Created attachment 177513 [details] Shar of a draft port for bazel at commit c1287f08f20a4ded This is a draft port for bazel at snapshot c1287f08f20a4ded (somewhere after the cutting point for 0.4.1 and well before 0.4.2) which is the first time a distribution archive can be built that only contains architecture independent files. It works on my stable/10 amd64 system, but I haven't tested it anywhere else. However, it shows the following. - The hanging of the compilation does not occur if the strategy for java compilation is changed from persistent workers to standalone javac invocations. - The initial building of protoc can be avoided, if a distribution archive[1] is used; those will be generated for all future releases (after 0.4.1 which is already cut). They can also be found in the https://bazel.googlesource.com/distfile/ repository. [1] https://bazel.build/designs/2016/10/11/distribution-artifact.html
(In reply to Yuri Victorovich from comment #18) Yes, the hanging of the default compilation is most likely due to a JDK bug. However, it is not true that this cannot be worked around. Changing the Javac strategy from worker to standalone, i.e., replacing ' --strategy=Javac=worker --worker_quit_after_build' by '--strategy=Javac=standalone' in scripts/bootstrap/bootstrap.sh works around the JDK issue. See also the patches in my proof-of-concept draft of a bazel port.
I see, the custom version of protobuf and other platform-specific parts aren't needed in 4.1rc and 4.2alpha. So let's wait for these versions to be released, and update the port based on the stable released version.
Created attachment 177659 [details] Shar of a draft port for bazel for version 0.4.2rc2 Updated by draft port to the second release candidate of bazel 0.4.2. Still only tested on stable/10 amd64.
Klaus, Ok with me, take over the bazel port and be a maintainer. Yuri
Testbuilds@work
Testbuild fine on 10.3i. Failed on 12a, 11a, 9.3a: http://people.freebsd.org/~pi/logs/devel__bazel-93a-1480919051.txt http://people.freebsd.org/~pi/logs/devel__bazel-11a-1480919051.txt http://people.freebsd.org/~pi/logs/devel__bazel-cur-1480919051.txt It looks like there's a patch needed to properly include definitions for time_t on 11 and 12. On 9.3, it something else. Can you update the shar ?
Created attachment 177702 [details] Shar of a draft port for bazel for version 0.4.2rc2 Thanks for running the test builds. For 11 (and probably 12 as well) the fix is already upstream (https://github.com/bazelbuild/bazel/commit/b3dc4cc13cd99f919075c36547a00a5475daed7a) and I updated the shar accordingly. For 9 I still have to investigate. I will report back, once I found out what is wrong there.
support for 9.x ends this month, so we'll mark it BROKEN for 9, it's a new port anyway.
(In reply to Klaus Aehlig from comment #27) Can you check the shar you uploaded ? If I compare it with the previous version, I don't see that update ?
Ignore my comment, I failed to see the patch-src_main_cpp_util_file__platform.h.
Committed, thanks!
A commit references this bug: Author: pi Date: Tue Dec 6 19:25:24 UTC 2016 New revision: 427983 URL: https://svnweb.freebsd.org/changeset/ports/427983 Log: New port: devel/bazel Bazel is Google's own build tool, now publicly available in Beta. Bazel has built-in support for building both client and server software, including client applications for both Android and iOS platforms. It also provides an extensible framework that you can use to develop your own build rules. WWW: https://bazel.build/ PR: 204512 Submitted by: Yuri Victorovich <yuri@rawbw.com>, Klaus Aehlig <aehlig@linta.de> Reviewed by: peterj Changes: head/devel/Makefile head/devel/bazel/ head/devel/bazel/Makefile head/devel/bazel/distinfo head/devel/bazel/files/ head/devel/bazel/files/patch-scripts_bootstrap_bootstrap.sh head/devel/bazel/files/patch-src_main_cpp_blaze__util__freebsd.cc head/devel/bazel/files/patch-src_main_cpp_util_file__platform.h head/devel/bazel/files/patch-third__party_protobuf_3.0.0_BUILD head/devel/bazel/pkg-descr