# toolchains Published articles for toolchains. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Announcing Fedora Linux 45 Beta DevFeed: [Announcing Fedora Linux 45 Beta]() Original publisher: [Read original article]() Author: Aoife Moloney Published: 2026-09-15T14:05:00Z Content type: release Language: en Sources: [Fedora Magazine]() Topics: [Fedora](), [Linux](), [dnf](), [podman](), [pandas](), [Python](), [gcc](), [Go Language](), [MariaDB](), [MySQL](), [Filesystems]() Tags: [2026](), [dnf](), [fedora-project-community](), [filesystems](), [gcc](), [go](), [linux](), [mysql](), [pandas](), [partitioning](), [podman](), [pre-release](), [python](), [release](), [toolchains]() ### AI overview Fedora Linux 45 Beta is available for download or upgrade on September 15, 2026. The release includes changes to the kernel console, package signature verification, desktop secret management, software versions, Atomic Desktop image builds, Fedora CoreOS swap support, Anaconda installation flows, and Stratis filesystem partitioning. ### Source excerpt Fedora Linux 45 Beta is here! On Tuesday, 15 September 2026 you can download or upgrade your systems from your usual spots to start enjoying what F45 has to offer early. How to get the beta release You can download F45 Beta, or our pre-release edition versions, from any of the following places: You can [...] ## Introducing CUDA Rust: Two Tracks for Writing GPU Kernels DevFeed: [Introducing CUDA Rust: Two Tracks for Writing GPU Kernels]() Original publisher: [Read original article]() Author: Elizabeth Goodman Published: 2026-09-08T12:00:00Z Content type: article Language: en Sources: [NVIDIA Developer](), [NVIDIA Technical Blog]() Topics: [GPU](), [Code generation](), [toolchain](), [C++]() Tags: [c-plus-plus](), [cuda](), [cuda-tile](), [data-science](), [developer-tools-techniques](), [dynamo](), [gpu](), [kernels](), [nemo-retriever](), [open-source](), [programming-languages-compilers](), [rust](), [toolchains]() ### AI overview NVIDIA introduces CUDA Rust for writing GPU kernels natively in Rust and compiling them to PTX. The article explains the SIMT and Tile programming tracks, recommends Tile as the default, and describes cuda-oxide's Rust-based code-generation path. ### Source excerpt In September 2026, NVIDIA announced it is leaning into native GPU programming in Rust. CUDA C++ and CUDA Python are mature, enterprise-grade toolchains, and... ## Kotlin Toolchain 0.12: Multiplatform Library Publishing, Wasm Apps, and More DevFeed: [Kotlin Toolchain 0.12: Multiplatform Library Publishing, Wasm Apps, and More]() Original publisher: [Read original article]() Author: Joffrey Bion Published: 2026-09-03T10:40:05Z Content type: release Language: en Sources: [Kotlin : A concise multiplatform language developed by JetBrains | The JetBrains Blog]() Topics: [toolchain](), [multiplatform](), [compose-hot-reload](), [web applications](), [Spring Boot 4]() Tags: [compose-hot-reload](), [gradle](), [intellij-idea](), [kotlin](), [multiplatform](), [news](), [publication](), [releases](), [toolchain](), [toolchains](), [wasm]() ### AI overview Kotlin Toolchain 0.12.0 adds multiplatform library publishing and previews support for building Wasm modules as web applications. It also includes command-line Compose Hot Reload and changes intended to reduce Maven Central publication files. ### Source excerpt Kotlin Toolchain 0.12.0 is out. This release brings some long-awaited features: multiplatform libraries publication, a preview of Wasm application support, Compose Hot Reload from the command line, and more. Read on for the details, and check the release notes for the full list of changes and bug fixes. Additionally, klibs.io now uses the Kotlin Toolchain [...] ## Google joins the OpenROAD Initiative as principal member to accelerate open source silicon innovation DevFeed: [Google joins the OpenROAD Initiative as principal member to accelerate open source silicon innovation]() Original publisher: [Read original article]() Author: Google Open Source (noreply@blogger.com) Published: 2026-08-11T18:30:00Z Content type: release Language: en Sources: [Google Open Source Blog]() Topics: [Google](), [Chip design](), [Open Source](), [toolchains](), [Continuous integration]() Tags: [chip-design](), [ci-cd](), [eda](), [google](), [open-source](), [openroad](), [semiconductors](), [toolchains](), [user-experience]() ### AI overview Google has joined the OpenROAD Initiative as a principal member and appointed Aaron Cunningham to its Governing Board. The partnership supports OpenROAD's open-source electronic design automation ecosystem through governance, ecosystem growth, workforce development, and technical improvements. ### Source excerpt by Ethan Mahintorabi & Aaron Cunningham, Hardware Toolchains Team Google is committed to advancing open source silicon innovation. We are excited to share that we have formally joined the OpenROAD Initiative (ORI), Inc. as a principal member. ORI is a nonprofit public benefit corporation dedicated to the open source electronic design automation (EDA) ecosystem. As part of this commitment, Aaron Cunningham has been appointed to the ORI Governing Board to represent Google and help drive the foundation's strategic direction, financial sustainability, and technical stewardship. Driving long-term open source sustainability The OpenROAD Initiative's mission is to advance and sustain the open source EDA ecosystem by fostering collaborative innovation across research, education, and industry--transforming ideas into silicon. Google's membership aligns directly with ORI's multi-year sustainability goals, supported by the US National Science Foundation's (NSF) Pathways to Enable Open-Source Ecosystems (POSE) program. With Google's participation and membership commitment, ORI will continue to strengthen, grow, and sustain its open source ecosystem through key vectors: Neutral Stewardship: Fostering transparent governance where no single company has outsized control over the code, ensuring the project remains inspectable, accessible, and community-driven. Ecosystem Growth: Supporting open and reproducible silicon research, developing robust design flows, and hosting global design contests. Workforce Development: Supporting global silicon skilling initiatives by expanding open source chip design curricula and collaborating with academic institutions and industrial training networks. Technical Strengthening: Enhancing continuous integration and deployment (CI/CD) pipelines, expanding PDK enablement, and improving user experience. Leadership perspectives "The OpenROAD Initiative is built on the vision of making chip design open and accessible to all--building a collaborative ecosyst ## GC and Exceptions in Wasmtime DevFeed: [GC and Exceptions in Wasmtime]() Original publisher: [Read original article]() Author: Nick Fitzgerald Published: 2026-07-20T00:00:00Z Content type: release Language: en Sources: [Bytecode Alliance]() Topics: [WebAssembly](), [wasm](), [Exception](), [toolchains]() Tags: [compilation](), [exceptions](), [release](), [toolchains](), [wasm](), [webassembly]() ### AI overview Wasmtime 47 enables the Wasm GC and exceptions proposals by default. The article explains how Wasm GC supports languages with object-and-reference data models by letting the runtime manage types and lifetimes, while the exceptions proposal provides more efficient exception handling for WebAssembly compilation targets. ### Source excerpt The Wasm GC and exceptions proposals are both enabled by default in today's Wasmtime 47 release! We are excited to help bring more languages to WebAssembly and everywhere that Wasmtime runs. Getting to this point involved large Wasmtime changes and represents the culmination of years of engineering effort. ## ESPHome 2026.7.0: Native toolchains by default DevFeed: [ESPHome 2026.7.0: Native toolchains by default]() Original publisher: [Read original article]() Author: Jesse Hills Published: 2026-07-15T00:00:00Z Content type: release Language: en Sources: [ESPHome - Smart Home Made Simple - Blog]() Topics: [esphome](), [toolchains](), [ESP32](), [Modbus](), [Security](), [ESP-IDF](), [SDK]() Tags: [2026](), [esp-idf](), [esp32](), [esphome](), [modbus](), [native](), [release](), [releases](), [security](), [toolchains]() ### AI overview ESPHome 2026.7.0 makes native ESP32 and nRF52 toolchains the default, adds security infrastructure including NVS encryption and OTA downgrade protection, and introduces a transport-agnostic provisioning component. The release also overhauls Modbus and includes performance, memory, LVGL, Ethernet, ESP-NOW, Zigbee, and component updates. ### Source excerpt ESPHome 2026.7.0 makes native toolchains the default on ESP32 and nRF52, adds EN18031 security groundwork, and overhauls Modbus. ## ESP-IDF v6.0: Default libc Switches from Newlib to PicolibC DevFeed: [ESP-IDF v6.0: Default libc Switches from Newlib to PicolibC]() Original publisher: [Read original article]() Author: John Lee Published: 2026-04-02T00:00:00Z Content type: article Language: en Sources: [Blog on Developer Portal]() Topics: [ESP-IDF](), [C](), [Embedded Systems](), [migration](), [Streams](), [Library](), [POSIX]() Tags: [apis](), [architectures](), [blog](), [c](), [compatibility](), [embedded](), [embedded-systems](), [esp-idf](), [firmware](), [libc](), [libraries](), [memory](), [migration](), [newlib](), [performance](), [picolibc](), [posix](), [streams](), [systems](), [toolchains]() ### AI overview ESP-IDF v6.0 changes its default C library from Newlib to PicolibC. The article compares the libraries' memory usage, standard I/O behavior, compatibility, and migration considerations, including measurements on ESP32-C3. ### Source excerpt ESP-IDF v6.0 switches the default C library from Newlib to PicolibC. This article compares both libraries in terms of memory usage, stdio behavior, compatibility, and migration tradeoffs, and explains when keeping Newlib still makes sense. ## ESP-IDF Installation Manager v0.8: Streamlined Setup for ESP-IDF Development DevFeed: [ESP-IDF Installation Manager v0.8: Streamlined Setup for ESP-IDF Development]() Original publisher: [Read original article]() Author: John Lee Published: 2026-03-02T00:00:00Z Content type: release Language: en Sources: [Blog on Developer Portal]() Topics: [ESP-IDF](), [cross-platform](), [Espressif](), [Package manager](), [CI/CD]() Tags: [beginner](), [blog](), [cross-platform](), [dependencies](), [eim](), [esp-idf](), [esp-idf-tool](), [espressif](), [gui](), [installation](), [linux](), [macos](), [offline](), [pipelines](), [release](), [reproducible-builds](), [toolchains](), [windows]() ### AI overview ESP-IDF Installation Manager v0.8 adds native package-manager installation methods, offline ESP-IDF installation, improved environment activation, CI/CD integration, and version management across Windows, macOS, and Linux. ### Source excerpt The ESP-IDF Installation Manager (EIM) v0.8 introduces simplified installation across Windows, macOS, and Linux through native package managers. This article covers the new release features, installation methods, offline capabilities, and headless usage for CI/CD pipelines. ## Architectural Choices in China's Open-Source AI Ecosystem: Building Beyond DeepSeek DevFeed: [Architectural Choices in China's Open-Source AI Ecosystem: Building Beyond DeepSeek]() Original publisher: [Read original article]() Author: Adina Yakefu; Irene Solaiman Published: 2026-01-27T15:01:45Z Content type: article Language: en Sources: [Hugging Face - Blog]() Topics: [Open Source](), [Artificial Intelligence](), [Mixture of Experts (MoE)](), [Hardware](), [multimodal](), [Open Source Models & Datasets](), [Inference](), [model-deployment](), [datasets](), [toolchains](), [stable-diffusion]() Tags: [ai](), [china](), [compute](), [datasets](), [deployment](), [evaluation](), [mixture-of-experts-moe](), [multimodal](), [open-source](), [performance](), [text-to-image](), [toolchains]() ### AI overview This second article in a three-part series examines architectural and hardware choices in China's open-source AI ecosystem after the DeepSeek Moment. It explains why Mixture-of-Experts architectures became widespread, emphasizing flexible compute allocation, sustainable cost-performance balance, deployment across varied hardware, and expansion into multimodal models, agents, datasets, evaluation, and toolchains. ### Source excerpt This is the second blog in a three-part series on China's open source community's historical advancements since January 2025's "DeepSeek Moment." The first blog is available here, and the third blog is available here. In this second piece we turn our focus from models to the architectural and hardware choices Chinese companies have made as openness becomes the norm. ## Engineers Want to Build, Not Maintain: Key Findings From Our 2026 Engineering Reality Report DevFeed: [Engineers Want to Build, Not Maintain: Key Findings From Our 2026 Engineering Reality Report]() Original publisher: [Read original article]() Published: 2025-10-08T00:00:00Z Content type: article Language: en Sources: [Chainguard: Unchained]() Topics: [Developer experience](), [code productivity](), [Artificial Intelligence](), [Automation](), [toolchains](), [Security]() Tags: [2026](), [ai](), [automation](), [chainguard](), [chainguard-containers-report](), [chainguard-report](), [developer-experience](), [developer-experience-report](), [engineering-reality](), [engineering-reality-2025](), [productivity](), [report](), [secure-software](), [security](), [software-engineer](), [toolchains]() ### AI overview Chainguard's 2026 Engineering Reality Report, based on a survey of 1,200 engineers and technology leaders, examines the modern developer experience. It finds that automation and AI are reducing repetitive work, while technical debt, maintenance, fragmented tooling, workflow disruption, burnout, and limited trust continue to constrain productivity. Engineers consistently want more time to build, and the article connects secure, integrated tools with innovation and business growth. ### Source excerpt Chainguard surveyed 1,200 engineers and technology leaders to better understand the state of the developer experience today and where teams can improve. ## Jane Street's 2025 Intern Projects: SQL Evaluation, OCaml Torch Bindings, and Cross-Process Memory Management DevFeed: [Jane Street's 2025 Intern Projects: SQL Evaluation, OCaml Torch Bindings, and Cross-Process Memory Management]() Original publisher: [Read original article]() Author: Yaron Minsky Published: 2025-08-27T00:00:00Z Content type: article Language: en Sources: [Jane Street]() Topics: [OCaml](), [SQL](), [torch](), [Process](), [systems]() Tags: [2025](), [internship](), [ocaml](), [process](), [sql](), [systems](), [toolchains]() ### AI overview Jane Street's 2025 internship roundup highlights projects involving a more efficient evaluator for its internal JSQL dialect, OCaml torch bindings designed for safe and deterministic tensor cleanup, and ref-counted memory management across processes in trading systems. It also briefly describes other intern work in testing, build systems, CSS tooling, OCaml, data warehousing, and simulation. ### Source excerpt Yet again, we're at the end of our internship season, and so it's time to summarize what the interns were up to! ## Finding unused targets with bazel DevFeed: [Finding unused targets with bazel]() Original publisher: [Read original article]() Author: Keith Smiley Published: 2025-03-24T18:00:00Z Content type: tutorial Language: en Sources: [Keith Smiley]() Topics: [Graphs](), [coding](), [Code](), [toolchains]() Tags: [bazel](), [build](), [code](), [coding](), [dependencies](), [graph](), [toolchains](), [use-cases]() ### AI overview This article explains how to use bazel query to inspect a build graph and identify unused targets. It presents a query that subtracts dependencies of top-level targets from all first-party targets, then discusses handling edge cases with kind filters and special tags such as allow-unused. It also describes tagging toolchains and other targets whose dependencies should be treated as used. ### Source excerpt Once you've fully migrated a codebase to bazel, one of the many advantages is that you can easily inspect your build graph using bazel query. One of the many things you can do with queries is write scripts to enforce coding standards, or in today's example, find unused targets that can lead to discovering unused code. The simplest version of this query starts like this: let all_targets = //... in let top_level_targets = tests($all_targets) union kind("(.*_binary) rule", $all_targets) in $all_targets - deps($top_level_targets) This initial version discovers all your first party targets, and then subtracts the dependencies of all "top level" targets, so that any remaining targets are considered unused. The idea of "top level" targets is better defined as: anything that you consider to be important enough that its dependencies are used. Depending on your codebase you might want to exclude test targets from this so that targets only in the dependencies of test targets are diagnosed as unused (this won't work if you have intentional testonly dependencies, although you could special case those as shown below). Once you have this initial query, you can start iterating in order to handle in edge cases. For example it's likely that you have some targets that aren't binaries or tests, but are considered used. There are 2 approaches I would recommend to handle this. First you can continue to build out the kind filter: kind("(.*_binary|platform|test_suite) rule", $all_targets) The downside with this approach is it can get unwieldy quickly. I like adding rules here that have many uses, but for other one off cases another approach you can use is to expand the query to look for special tags: let all_targets = //... in let top_level_targets = tests($all_targets) union kind("(.*_binary|platform|test_suite) rule", $all_targets) in let allowed_unused = attr(tags, allow-unused, $all_targets) in $all_targets - deps($top_level_targets) - $allowed_unused Then you can add tags = ["allow-un ## Using Renovate to update build JDK DevFeed: [Using Renovate to update build JDK]() Original publisher: [Read original article]() Published: 2025-01-08T00:00:00Z Content type: tutorial Language: en Sources: [Jake Wharton]() Topics: [Java](), [GitHub Actions](), [ci](), [Spring Boot](), [JSON](), [Development](), [Homebrew](), [toolchains]() Tags: [build](), [ci](), [dependencies](), [github-actions](), [gradle](), [java](), [jdk](), [json](), [jvm](), [renovate](), [toolchains](), [update]() ### AI overview This article explains how to use Renovate to keep the JDK used by a GitHub Actions CI build updated automatically. It moves the Java version into a .github/.java-version file, configures setup-java to read that file, and adds a custom regex manager in renovate.json to update the file. The approach allows local development with the latest JDK while preserving compatibility with older Java versions for targeting and testing. ### Source excerpt You want to be using the latest JDK for development. Don't use Gradle toolchains, they'll needlessly force you to use old JDKs. You can still target and test on old JVM versions but develop with the latest and greatest. Java and the JDK are literally built for this. Locally this hasn't been a problem. Homebrew (or your favorite equivalent) will keep your default JDK at the latest. Keeping my GitHub actions up-to-date, however, frequently slips my mind. I find projects using 19 or 20 simply because I haven't touched the CI build in the two years since 19 or 20 was the latest. We're already using Renovate to keep dependencies up to date. With a little extra programming in JSON (wince) we can have the JDK version updated to latest as well. First, migrate the existing build JDK version in your GitHub Action to a .github/.java-version file1. 21 Next, change the setup-java action to use this file rather than a hard-coded version. - uses: actions/setup-java@v4 with: distribution: 'zulu' - java-version: 21 + java-version-file: .github/.java-version Finally, in your renovate.json52, add a custom manager to update this file3. ignorePresets: [ // Ensure we get the latest version and are not pinned to old versions. 'workarounds:javaLTSVersions', ], customManagers: [ // Update .java-version file with the latest JDK version. { customType: 'regex', fileMatch: [ '\\.java-version$', ], matchStrings: [ '(?.*)\\n', ], datasourceTemplate: 'java-version', depNameTemplate: 'java', // Only write the major version. extractVersionTemplate: '^(?\\d+)', }, ], Commit, push, and wait for Renovate to send you a PR4. Now your CI build automatically tracks the latest JDK. I'm putting the .java-version file into the .github/ folder because I don't want to force this version on people using jenv or the like. The whole point of this setup is you can build with any version of Java newer than our very, very old baseline of Java 8 (although things like Gradle have a higher minimum ## Gradle toolchains are rarely a good idea DevFeed: [Gradle toolchains are rarely a good idea]() Original publisher: [Read original article]() Published: 2024-03-21T00:00:00Z Content type: opinion Language: en Sources: [Jake Wharton]() Topics: [Gradle](), [toolchains](), [Java](), [Containers](), [ci](), [Homebrew](), [Kotlin]() Tags: [ci](), [containers](), [go](), [gradle](), [java](), [toolchains]() ### AI overview The article argues that Gradle Java toolchains are often counterproductive. Using an old JDK can produce outdated, non-searchable Javadoc, ignore container resource limits, and increase the risk of compiler and JVM bugs. The author recommends building with a modern JDK while controlling the target language level through compiler configuration, and keeping installed JDKs up to date. ### Source excerpt The last post featured some Kotlin code inadvertently targeting a new Java API when the build JDK was bumped to 21. This can be solved with the -Xjdk-release Kotlin compiler flag, or by using Gradle toolchains to build with an old JDK. If you read the Gradle docs... Using Java toolchains is a preferred way to target a language version ...or the Android docs... We recommend that you always specify the Java toolchain ...you wouldn't be blamed for thinking Java toolchains are the way to go! However, Java toolchains are rarely a good idea. Let's look at why. Bad docs Last week I released a new version of Retrofit which uses a Java toolchain to target Java 8. Its use of toolchains was contributed a while ago, and I simply forgot to remove it. As a consequence, its Javadoc was built using JDK 8 and is thus not searchable. Searchable Javadoc came in JEP 225 with JDK 9. The next release of Retrofit will be made without a toolchain and with the latest JDK. Its docs will have all the Javadoc advancements from the last 10 years including search and better modern HTML/CSS. Resource ignorance Old JVMs were somewhat notorious for being ignorant to resource limitations imposed by the system. The rise of containers, especially on CI systems, means your process resource limits are different from those of the host OS. JDK 10 kicked things into high gear with cgroups support and JDK 15 extended that to cgroups2. Both of those changes were backported to the 8 and 11 branches, but since Gradle toolchains will use an already-installed JDK if available you have to have kept your JDK 8 and/or JDK 11 up-to-date. Have you? Not to stray too far off-topic, but if you installed it with SDKMAN! or similar JDK management tools there's a good chance it's wildly out of date. I keep all my JDKs up-to-date by installing them through a Homebrew tap which itself updates automatically using the Azul Zulu API. As long as I do a brew upgrade every so often, each major JDK release that I have installed will be upd ## Building with nightly Swift toolchains on macOS DevFeed: [Building with nightly Swift toolchains on macOS]() Original publisher: [Read original article]() Author: Ole Begemann Published: 2024-03-05T18:54:44Z Content type: tutorial Language: en Sources: [Ole Begemann]() Topics: [Swift](), [toolchains](), [macOS](), [Command-line interface](), [Xcode](), [Package manager]() Tags: [command-line](), [macos](), [swift](), [swift-package-manager](), [toolchains](), [xcode]() ### AI overview A practical guide to installing and selecting nightly Swift compiler toolchains on macOS. It covers using custom toolchains in Xcode and from the command line, including the TOOLCHAINS environment variable and bundle IDs. The article also notes limitations such as unsupported playgrounds, built-in Swift Package Manager behavior, and App Store submission restrictions. ### Source excerpt The Swift website provides nightly builds of the Swift compiler (called toolchains) for download. Building with a nightly compiler can be useful if you want to check if a bug has already been fixed on main, or if you want to experiment with upcoming language features such as Embedded Swift, as I've been doing lately. A toolchain is distributed as a .pkg installer that installs itself into /Library/Developer/Toolchains (or the equivalent path in your home directory). After installation, you have several options to select the toolchain you want to build with: In Xcode In Xcode, select the toolchain from the main menu (Xcode > Toolchains), then build and/or run your code normally. Not all Xcode features work with a custom toolchain. For example, playgrounds don't work, and Xcode will always use its built-in copy of the Swift Package Manager, so you won't be able to use unreleased SwiftPM features in this way. Also, Apple won't accept apps built with a non-standard toolchain for submission to the App Store. On the command line When building on the command line there are multiple options, depending on your preferences and what tool you want to use. The TOOLCHAINS environment variable All of the various Swift build tools respect the TOOLCHAINS environment variable. This should be set to the desired toolchain's bundle ID, which you can find in the Info.plist file in the toolchain's directory. Example (I'm using a nightly toolchain from 2024-03-03 here): # My normal Swift version is 5.10 $ swift --version swift-driver version: 1.90.11.1 Apple Swift version 5.10 (swiftlang-5.10.0.13 clang-1500.3.9.4) # Make sure xcode-select points to Xcode, not to /Library/Developer/CommandLineTools # The Command Line Tools will ignore the TOOLCHAINS variable. $ xcode-select --print-path /Applications/Xcode.app/Contents/Developer # The nightly toolchain is 6.0-dev $ export TOOLCHAINS=org.swift.59202403031a $ swift --version Apple Swift version 6.0-dev (LLVM 0c7823cab15dec9, Swift 0cc0590933 ## Dev Mode: Building a design tool that works harder for developers DevFeed: [Dev Mode: Building a design tool that works harder for developers]() Original publisher: [Read original article]() Author: Alia Fite Published: 2023-11-22T00:00:00Z Content type: article Language: en Sources: [Figma Blog]() Topics: [Figma](), [developer tooling](), [toolchains](), [React](), [Code generation]() Tags: [code](), [developer-tooling](), [developers](), [development](), [figma](), [product-design](), [react](), [tool](), [toolchains](), [workflows]() ### AI overview Figma describes how its Dev Mode team built a developer-focused experience within the design tool. The team moved away from a code-generation-first approach, studied developer workflows and toolchains, and accelerated development through its 2021 acquisition of Visly, whose team had built a tool for developing UI components in React. ### Source excerpt How do you create a home for developers in a design tool? The Dev Mode team shares their early pivot away from a codegen-first approach, the acquisition that accelerated their efforts, and what it means to break down the handoff wall. ## Announcing Lit 3.0 Pre-releases DevFeed: [Announcing Lit 3.0 Pre-releases]() Original publisher: [Read original article]() Author: Justin Fagnani Published: 2023-05-15T00:00:00Z Content type: release Language: en Sources: [Lit Blog]() Topics: [releases](), [Web Components](), [Web](), [npm](), [toolchains](), [interoperability](), [Server-side rendering]() Tags: [browser](), [compatibility](), [interoperability](), [npm](), [packages](), [pre-release](), [release](), [releases](), [ssr](), [testing](), [toolchains](), [tooling](), [upgrade]() ### AI overview The Lit team announces the first Lit 3.0 pre-releases. This major version introduces a small set of breaking changes focused on browser support, deprecated APIs, package publishing, and SSR hydration modules, while adding no new features. Lit 2.x users without deprecation warnings should generally have a seamless upgrade, although some may need newer tooling because Lit's npm modules are now published as ES2021. ### Source excerpt Get an early look at the upcoming Lit 3.0 release. ## Google's Fully Homomorphic Encryption Compiler -- A Primer DevFeed: [Google's Fully Homomorphic Encryption Compiler -- A Primer]() Original publisher: [Read original article]() Published: 2023-02-13T11:34:01Z Content type: article Language: en Sources: [Jeremy Kun]() Topics: [homomorphic encryption](), [FHE](), [C++](), [Compiler](), [Google](), [GitHub](), [Open Source](), [toolchain]() Tags: [c-plus-plus](), [circuit](), [compiler](), [encryption](), [fhe](), [github](), [google](), [homomorphic-encryption](), [how-to](), [open-source](), [toolchains]() ### AI overview This primer introduces Google's open-source fully homomorphic encryption compiler for C++. It explains how the compiler transforms supported plaintext C++ programs into programs that operate on encrypted data, and briefly discusses its internals, optimization passes, and circuit-based toolchain model. ### Source excerpt Back in May of 2022 I transferred teams at Google to work on Fully Homomorphic Encryption (newsletter announcement). Since then I've been working on a variety of projects in the space, including being the primary maintainer on github.com/google/fully-homomorphic-encryption, which is an open source FHE compiler for C++. This article will be an introduction to how to use it to compile programs to FHE, as well as a quick overview of its internals. ## Build on latest Java, test through lowest Java DevFeed: [Build on latest Java, test through lowest Java]() Original publisher: [Read original article]() Published: 2022-05-17T00:00:00Z Content type: tutorial Language: en Sources: [Jake Wharton]() Topics: [ci](), [Gradle](), [Java](), [Testing](), [toolchains](), [Open Source]() Tags: [ci](), [gradle](), [java](), [open-source](), [testing](), [toolchains](), [verification]() ### AI overview This article explains how to use Gradle toolchains to compile a Java project once with the latest Java version while running tests across every supported version down to the lowest. The approach reduces CI workload and is especially useful for projects whose behavior or API usage varies by Java version. ### Source excerpt In the past, when a new version of Java was released, I would add that version to our open source project's CI builds. strategy: matrix: java-version: - 8 - 9 ⋮ - 17 + - 18 This ensures that each project can be built and its tests pass on every major version. But this makes no sense! No user is building these projects on different versions. No user is building these projects at all. Consumers are using the pre-built .jar which we ship to Maven Central built on a single version. Testing on every version, however, is something extremely valuable. Thankfully, Gradle toolchains let us retain this while still only building once. First, CI only has to build on a single version. We choose the latest because Java has excellent cross-compilation capabilities, and we want to be using the latest tools. - uses: actions/setup-java@v2 with: distribution: 'zulu' - java-version: ${{ matrix.java-version }} + java-version: 18 Second, unchanged from before, we still target whichever Java version is the lowest supported through either the --release flag or sourceCompatibility/targetCompatibility per the Gradle docs. And finally, we set up tests to run on every supported version. // Normal test task runs on compile JDK. (8..17).each { majorVersion -> def jdkTest = tasks.register("testJdk$majorVersion", Test) { javaLauncher = javaToolchains.launcherFor { languageVersion = JavaLanguageVersion.of(majorVersion) } description = "Runs the test suite on JDK $majorVersion" group = LifecycleBasePlugin.VERIFICATION_GROUP // Copy inputs from normal Test task. def testTask = tasks.getByName("test") classpath = testTask.classpath testClassesDirs = testTask.testClassesDirs } tasks.named("check").configure { dependsOn(jdkTest) } } This setup reduces CI burden since we only compile the main and test sources once but execute the tests on every supported version from latest to lowest. Verification tasks ------------------ check - Runs all checks. test - Runs the test suite. testJdk10 - Runs the test sui ## How to Integrate Just-In-Time Access Requests into Your DevOps Workflow DevFeed: [How to Integrate Just-In-Time Access Requests into Your DevOps Workflow]() Original publisher: [Read original article]() Author: info@goteleport.com (Steven Martin) Published: 2021-11-11T00:00:00Z Content type: tutorial Language: en Sources: [Teleport]() Topics: [DevOps](), [Zero Trust](), [certificates](), [toolchains](), [Command-line interface](), [Containers](), [Slack](), [email](), [GitLab](), [Amazon EC2]() Tags: [api](), [aws](), [containers](), [devops](), [email](), [gitlab](), [how-to](), [implement](), [jira](), [least-privilege](), [on-call](), [organization](), [pagerduty](), [request](), [server](), [speed](), [ssh](), [toolchains](), [workflow](), [zero-trust]() ### AI overview This tutorial explains how Teleport Access Requests provide temporary elevated infrastructure access for DevOps workflows. It covers approval through command-line, web console, and plugins such as Slack, PagerDuty, Jira, Email, and GitLab, with short-lived certificates reverting to default roles after the access period. ### Source excerpt Just-in-time access requests enable DevOps teams to implement least privilege without introducing roadblocks to productivity. This post shows you how to get started. ## Introducing Java toolchains DevFeed: [Introducing Java toolchains]() Original publisher: [Read original article]() Author: Louis Jacomet Published: 2020-10-30T04:00:00Z Content type: tutorial Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [Java](), [toolchains](), [configuration](), [Testing](), [Code]() Tags: [build](), [compilation](), [configuration](), [gradle](), [how-to](), [install](), [installation](), [java](), [jdk](), [project](), [run](), [test](), [testing](), [toolchains]() ### AI overview This article introduces Java toolchain support in Gradle 6.7. It explains how to declare a project's required Java version in one place so Gradle can use that version for compilation, testing, documentation, and application execution, while allowing Gradle itself to run with another installed Java version. Gradle can detect suitable JDK installations and download a required JDK when necessary. ### Source excerpt Building a Java project and running Gradle both require the installation of a JDK. Most Gradle users conveniently use the Java installation that is running Gradle to build and test their application. While this is acceptable in simple cases, there are a number of issues with this approach. For example, if a build requires the same Java version to be used on all machines, each developer needs to know about that requirement and install that version manually. It has been possible to configure Gradle to build a project with a different Java version than the one used to run Gradle. However, it has required configuring each task like compilation, test, and javadoc separately. Gradle 6.7 introduces "Java toolchain support". In a nutshell, it allows you to run Gradle with whatever version of Java you have installed, while Gradle builds the project with the version of Java declared in a single place. Gradle will automatically configure the build, detect already installed JDKs and download the required JDK if it is not already installed. No more release or sourceCompatibility tweaks, no more wiki pages describing which JDK you should install for the build to work. The advantages are tremendous, let's see how to use this! Introducing Java toolchains support Java toolchains support enables build authors to declare which Java version their project requires for compiling, testing and running their code. Project wide configuration Let's start with what you, as a build author, need to do, at the minimum: plugins { id("java-library") // or id("application") } java { toolchain { languageVersion.set(JavaLanguageVersion.of(11)) } } And that's it! What do you get with the above in Gradle 6.7? You get: All Java compilation tasks will use Java 11 to build. That means code in the main and test source sets, but also Java code in any custom source set you add, will be built with the configured Java version. All tests tasks, including the default test task and any additional custom Test task, ## On GitHub Actions with MSYS2 DevFeed: [On GitHub Actions with MSYS2]() Original publisher: [Read original article]() Published: 2020-08-01T03:33:31Z Content type: tutorial Language: en Sources: [Ariya Hidayat]() Topics: [GitHub Actions](), [CI/CD](), [C](), [gcc](), [GitHub](), [toolchain](), [Windows](), [Shell]() Tags: [architecture](), [c](), [clang](), [compilers](), [continuous-integration](), [gcc](), [github](), [github-actions](), [toolchains](), [windows](), [yaml]() ### AI overview A practical guide to using GitHub Actions with MSYS2 to build an ANSI C program on Windows. It shows configurations for GCC and Clang, then uses matrix parameters to cover both i686 and AMD64 architectures. ### Source excerpt Thanks to the complete GitHub Actions for MSYS2, it is easier than ever to construct a continuous integration setup for building with compilers and toolchains which can run on MSYS2. ## Cross-compiling with musl Toolchains DevFeed: [Cross-compiling with musl Toolchains]() Original publisher: [Read original article]() Published: 2020-06-22T12:37:59Z Content type: tutorial Language: en Sources: [Ariya Hidayat]() Topics: [Cross-Compilation](), [toolchains](), [Linux](), [Zig](), [C](), [qemu](), [ci](), [make]() Tags: [c](), [compiler](), [continuous-integration](), [cross-compilation](), [docker](), [linux](), [make](), [mips](), [qemu](), [toolchains](), [windows](), [x86]() ### AI overview A tutorial on using static musl-based toolchains to cross-compile command-line programs for multiple targets, including MIPS and Windows, from a Linux x86-64 host. It also covers testing non-native binaries with QEMU and migrating FastLZ continuous integration to musl.cc. ### Source excerpt When working on command-line utilities which can be useful for various platforms, from Windows on x86 to Linux on MIPS, the existence of a cross-compilation is highly attractive. A number of different binaries can be constructed conveniently from a single, typically powerful host system. ## Shipping Binary Frameworks With Swift 5.0 DevFeed: [Shipping Binary Frameworks With Swift 5.0]() Original publisher: [Read original article]() Author: Chris Williams Published: 2019-05-31T09:00:00Z Content type: tutorial Language: en Sources: [Square Corner Blog](), [Square Corner Blog RSS Feed]() Topics: [Swift](), [Framework](), [Objective-C](), [Xcode]() Tags: [binaries](), [bridge](), [bridging](), [compatibility](), [engineering](), [how-to](), [objective-c](), [swift](), [toolchains](), [xcode]() ### AI overview This tutorial explains how to ship binary frameworks with Swift 5.0. It covers ABI stability, the future role of module stability, and using Objective-C bridging to provide a more stable interface across Swift toolchain versions. ### Source excerpt How to get a binary framework shipped with Swift 5.0