Created attachment 261268 [details] [PATCH] devel/bazel: update to 8.2.1 Patch attached. Tested using cpp examples from https://github.com/bazelbuild/examples and it works well. Since this was a lot of work to update to latest upstream stable version, this requires a bit more testing. Can someone try on their bazel projects and report back?
This seems to be fine in my limited testing, but I mostly abandoned my tcmalloc work.
Are there any test suites or projects that I can use to run this patch on and verify?
Please run against at least existing ports consumers and report back. You may find that certain projects only build against one specific bazel major version, amongst other issues, which is why we need multiple versions in the tree.
Created attachment 262384 [details] [PATCH] devel/bazel: update to 8.3.1 Attaching refreshed patch to latest upstream 8.3.1. (In reply to Charlie Li from comment #3) There are currently no consumers of 'devel/bazel' in the ports tree. There is one that is commented out (net/gitlab-agent), and the rest of them strictly depend on 'devel/bazel5'. It would be good to get this in so that people can start contributing ports that DO depend on bazel 8 onwards.
Any updates on reviewing this?
(In reply to Siva Mahadevan from comment #4) Okay, if that's the case then please name this port bazel8, rename the existing bazel to bazel6 (and re point the ports that depend on it to bazel6), and make a new bazel port that just points to this one (like drm-kmod does).
Created attachment 264733 [details] [PATCH] devel/bazel8: new port I'll first post a new port for bazel8 so that people can start testing with it, then post the renames afterward.
Hi, I'm interested in this as MongoDB 8.0 moved to Bazel I'm a bit stuck in updating my databases/mongodb80 port to the latest version. 🏆 So you will have at least one consumer of this port in the near future.
A quick update from todays experiment. Building bazel8 went fine on my RPI4/aarch64 14.3-RELEASE. Running it gives this error: $ bazel file is invalid or corrupted (missing end of central directory record) Opening zip "/usr/local/bin/bazel": Cannot find central directory FATAL: Failed to open '/usr/local/bin/bazel' as a zip file: (error: 5): Input/output error $ file /usr/local/bin/bazel /usr/local/bin/bazel: ELF 64-bit LSB executable, ARM aarch64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 14.3, FreeBSD-style, stripped I have no idea what this could mean. Looking at the output of truss bazel starts fine and then it tries to open itself, does an lseek and mmap and prints an error about not being a zip format. ... [snip] ... openat(AT_FDCWD,"/usr/local/bin/bazel",O_RDONLY,00) = 3 (0x3) lseek(3,0x0,SEEK_END) = 5285472 (0x50a660) mmap(0x0,5285472,PROT_READ,MAP_PRIVATE,3,0x0) = 2250244096 (0x86200000) file is invalid or corrupted (missing end of central directory record) write(2,"file is invalid or corrupted (mi"...,71) = 71 (0x47) Opening zip "/usr/local/bin/bazel": Cannot find central directory write(2,"Opening zip "/usr/local/bin/baze"...,66) = 66 (0x42) If you prefer to talk about this via private mail or a mailing list, that is fine by me.
(In reply to Ronald Klop from comment #9) Ah, I think I forgot to disable stripping the binary in this patch. I'll post a v2 shortly.
Ok, thanks. Bazel runs a lot better after adding STRIP= like the bazel6 port does. I noticed that the port takes as much CPUs as are available. On the FreeBSD build cluster it shares the CPU with a lot of other build jobs. You can pass something like --local_resources=cpu=${MAKE_JOBS_NUMBER} via EXTRA_BAZEL_ARGS to make it adhere to what the build cluster tries to assign.
Created attachment 265215 [details] [PATCH v2] devel/bazel8: new port Thanks for the help, applied feedback and STRIP fix in v2.
^Triage: adding new port tag to summary
Nit: usually, we want to use the comment to be the same as the GitHub description unless it sucks. Their GitHub description currently say "a fast, scalable, multi-language and extensible build system", but that's too long and also not that descriptive. I use pkg search -c a lot. People know this as Google's build system. Can we call it that somehow in the comments instead of fast and correct, which is extremely subjective, opinionated, and dubious?"
Created attachment 265221 [details] [PATCH v3] devel/bazel8: Google's multi-language and extensible build system How does v3's COMMENT look? I think this is descriptive and objectively worded.
FYI: Existing work by Ken DEGUCHI, implemented as overlay. https://github.com/kdeguchi/mozc-ports As you can see there, japanese/mozc-server newer than in-tree version (supporting textproc/fcitx5) requires bazel8 to build.
I vote for committing this. It compiles. It runs. Further refinement (if needed) can be done in follow up issues/commits. Also, when it is in the ports tree it is easier for people to start using this and that is the next phase this port needs to enter IMHO. I have a ports commit bit and can commit it for you. But I don’t want to step on other people’s toes if they still have concerns about the patch.
This is going to be an update to the main devel/bazel port, after I get a chance to build it myself. The existing version 6 gets moved to a new port. Feel free to keep submitting stuff but this is staying under one maintainer. As much as this is an albatross in the greater scheme of things, there are other items to be done particularly making a framework around this for easier use within the tree.
(In reply to Charlie Li from comment #18) Hi, out of curiosity, any news on the progress?
I can update my patch to latest bazel8 8.5.1, but bazel 9 has just officially released. @vishwin are you already working on creating a port for it, or should I? > Feel free to keep submitting stuff but this is staying under one maintainer. I will ensure that you are kept as the maintainer.
Created attachment 267466 [details] [PATCH] devel/bazel9: new port Looks like that was as easy as just changing the version number from the bazel8 patch I had. I'm obsoleting the old one, since we probably want to skip bazel8 and go right to bazel9.
(In reply to Siva Mahadevan from comment #21) May we have devel/bazel8 and devel/bazel9? bazel9 dropped WORKSPACE support, while there are many bazel repository still using WORKSPACE, so bazel8 will be also needed.
(In reply to Hiroo Ono from comment #22) So something like done for gcc is wanted? devel/bazel to be metaport for pointing default version (or choose one via OPTIONS) and numbered ports for each version?
> So something like done for gcc is wanted? > devel/bazel to be metaport for pointing default version I like this idea for future changes, but for now, I'll attach two patches to this bug report: one for bazel8 and one for bazel9. Once vishwin@ tests it and merges it, then we can update the current bazel port as a metaport after migrating it to bazel6. I'll work on this today sometime and post back soon.
(In reply to Siva Mahadevan from comment #24) Thanks! Looks reasonable workflow.
Created attachment 267557 [details] [PATCH] devel/bazel8: new port Added bazel 8.5.1 and switched maintainer to vishwin@ in the patch.
Created attachment 267558 [details] [PATCH v2] devel/bazel9: new port Rebased and re-tested bazel9 patch.
Should all bazel ports be numbered (devel/bazelN) instead of updating devel/bazel? It seems that too many users are bazel version-specific.
Also: devel/bazel7: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294033
(In reply to Yuri Victorovich from comment #28) I think so. As I've written in Comment 23, making each actual ports versioned and making devel/bazel to be metaport pointing to default (or chozen by OPTIONS) version would be most reasonable way to go.
(In reply to Tomoaki AOKI from comment #30) +1
Is this bug superseded by the bazel8 and bazel9 ports committed a couple days ago?
(In reply to Alex O'Brien from comment #32) I guess so, although it's sad that this bug wasn't noticed when it got committed. I'll let vishwin@ decide what to do about this bug.