fosstodon.org is one of the many independent Mastodon servers you can use to participate in the fediverse.
Fosstodon is an invite only Mastodon instance that is open to those who are interested in technology; particularly free & open source software. If you wish to join, contact us for an invite.

Administered by:

Server stats:

10K
active users

#bazel

0 posts0 participants0 posts today

The #s390x open source software team at IBM confirms the latest versions of various software packages run well on #Linux on #IBMZ & #LinuxONE

In February 2025 validation was maintained for over 3 dozen projects, including the #Apache HTTP server, #Bazel and #etcd

Plus, community CI and docs were added to go-mysql, and fastfetch added CI & began releasing binaries with v2.36.0!

Full report + how your project can apply for a s390x VM: community.ibm.com/community/us

community.ibm.com · Linux on IBM Z and LinuxONE Open Source Software Report: February 2025

'build without the bytes' is a blog post written by Chi Wang at Google in 2023, regarding Bazel 7 enabling it by default, but I think it's a cool concept, and feels more relevant in the age of ML and AI development

for example, your deployment might transitively need a graph of large files, but by agreeing to use a manifest of those files, the machine image that's doing the deploying would just need the manifest. #Bazel 6/7's bwob can cut GBs of downloads
blog.bazel.build/2023/10/06/bw

blog.bazel.buildBuild without the Bytes is enabled by default in Bazel 7

Ok #rust folks, here is a head scratcher:

#Cargo builds the re_log crate, and #buck2 builds the re_log crate.

#Bazel does not.

Every build is using rustc 1.84.0.

The error is:

```
error[E0015]: cannot call non-const fn `parking_lot::lock_api::RwLock::<parking_lot::RawRwLock, Vec<&dyn Log>>::new` in constant functions
--> ext/crates/re_log-0.22.0/src/multi_logger.rs:45:22
|
45 | loggers: parking_lot::RwLock::new(vec![]),
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: calls in constant functions are limited to constant functions, tuple structs and tuple variants

error: aborting due to 1 previous error

For more information about this error, try `rustc --explain E0015`.
```

All builds are correctly using parking_lot 0.12.3.

Here are the rustc invocations used by cargo and bazel: paste.sr.ht/~photex/e5e8d7405a

I can't spot any appreciable difference.

#buck2 is currently a more successful exploration than #bazel has been for some parts of our #rust project.

Much faster than cargo.

One thing I'm very stuck on is how to control the name of a cdylib. The stupid hash is there, but that breaks the ability of it to be loaded correctly (it's a plugin).

Wanted to install #Bazel (the Google build system) on my Mac. The first thing they do is make me decide whether to install Bazel itself or install Bazelisk, a tool that installs Bazel.

Honestly, WTF are we doing, software people?

That time of the year when I feel the urge to write my own build/integration system again.

#Bazel is a pain to extend and has many idiosyncracies. Also code base is way too complex and hard to penetreate. It feels generally stuck in a local maximum.

#Buildstream is pretty cool and extensible but variation support is not very elegant. It also still needs an inner build system. Also yaml 😒

#Pants seemed to be a step in the right direction. Amazingly simple extensibility. But still felt like the the build variation capabilites were not that strong. Also no support for C++.

I like starlark itself.

Does anybody know of any build system "framework" which I can just plug an play on a build tree so that I don't have to write the ugly parts of dealing with the compiler and focus on building the nice constructs for describing that build tree?

and are both totalizing systems. They require big ecosystems and large user investment because they expect the entire system to work "their way". (I use and like them both).

Are there build systems exploring more interoperability with off-the-shelf tools like npm, pip, cargo, and friends? Building interfaces to define reproducible steps, cache units, all that good stuff?

Got side-tracked on a project where step 1 is converting something from Autotools to Bazel. The lack of a sufficiently functional "make install" in Bazel is disappointing but not surprising, and I'll just live with that for now. Shell scripts won't save us, but they'll get us where we want to go until there's time to build something better. (Writing Starlark rules is not very fun.)