Connect with us

Entwicklung & Code

CMake 4.3 bringt Common Package Specification und Build-Profiling


Kitware hat Version 4.3 seines weit verbreiteten Build-Systems CMake veröffentlicht. Die wichtigste Neuerung ist die Unterstützung der Common Package Specification (CPS) – ein JSON-basiertes Format, das Softwarepakete herstellerneutral beschreibt. Daneben führt das Release ein Instrumentation-Framework ein, mit dem Entwickler Timing-Daten und Systemdiagnosen während des gesamten Build-Prozesses erfassen können.

Weiterlesen nach der Anzeige

Das Build-System CMake gilt als De-facto-Standard für C- und C++-Projekte und wird sowohl in zahlreichen Open-Source- als auch in kommerziellen Projekten eingesetzt. Bisher konnten Paketbeschreibungen nur in der CMake-eigenen Sprache ausgetauscht werden. Die CPS-Spezifikation liegt aktuell in Version 0.14.1 vor und soll die Interoperabilität zwischen verschiedenen Build-Systemen verbessern, indem Paketbeschreibungen in einem Format ausgetauscht werden können, das laut Ankündigung von Kitware nicht an die CMake-eigene Sprache gebunden ist.

Common Package Specification: Paketbeschreibungen jenseits der CMake-Syntax

Die Common Package Specification beschreibt Binärpakete – also Bibliotheken, Header und Tools – in einem maschinenlesbaren JSON-Format, das unabhängig vom jeweiligen Build-System funktioniert. CPS-Dateien enthalten Informationen zu Interface-Targets, unterstützten Konfigurationen pro Architektur, Versionskompatibilität und Lizenzangaben. Damit können Build-Systeme wie CMake, aber auch Paketmanager wie Conan, dieselben Paketbeschreibungen nutzen, ohne sie in ein proprietäres Format übersetzen zu müssen.

Konkret hat Kitware in CMake 4.3 drei zentrale Integrationspunkte geschaffen: Der Befehl find_package() durchsucht nun auch CPS-Pakete und kann diese importieren. Die Befehle install() und export() erhielten ein neues Subcommand PACKAGE_INFO, mit dem sich CPS-Beschreibungen erzeugen lassen. Zudem versteht der project()-Befehl jetzt die Optionen COMPAT_VERSION und SPDX_LICENSE, die bei der CPS-Erzeugung automatisch übernommen werden. Experimentelle CPS-Unterstützung gab es bereits in früheren 4.x-Versionen – mit CMake 4.3 gilt das Feature laut den Release Notes nun als stabil.

Instrumentation: Build-Prozesse durchleuchten

Wer wissen will, wo die Build-Zeit tatsächlich verrinnt, bekommt mit cmake-instrumentation(7) ein neues Werkzeug an die Hand. Das Framework sammelt während aller Phasen – Konfiguration, Generierung, Kompilierung, Test und Installation – granulare Daten zu Laufzeiten, Exit-Codes und Systemmetriken wie CPU-Auslastung und Speicherverbrauch. Die Messwerte landen in indexierten Snippet-Dateien im Build-Verzeichnis und lassen sich über Callbacks weiterverarbeiten.

Weiterlesen nach der Anzeige

Besonders praktisch für die Analyse: CMake 4.3 kann die Instrumentierungsdaten im Google Trace Event Format ausgeben. Damit lassen sich Build-Abläufe in gängigen Trace-Viewern wie Perfetto visualisieren – Engpässe in der Kompilierung oder bei der Link-Phase werden so auf einen Blick sichtbar. Zusätzlich fließen die Daten in CDash-Submissions ein, sodass Teams ihre Build-Performance auch im CI/CD-Betrieb überwachen können. Die Aktivierung erfolgt wahlweise über den neuen Befehl cmake_instrumentation() oder über JSON-basierte Query-Dateien auf Projekt- oder Nutzerebene.

Weitere Neuerungen im Überblick

Neben den beiden Highlights bringt CMake 4.3 zahlreiche weitere Verbesserungen mit. Die Archiv-Operationen über cmake -E tar und file(ARCHIVE_CREATE) unterstützen nun Multithreading über ein neues --cmake-tar-threads-Flag, zusätzliche Kompressionsmethoden wie LZMA und PPMd für das 7zip-Format sowie konfigurierbare Kompressionslevel. Das neue Kommandozeilenwerkzeug cmake -E bin2c wandelt Binärdateien in C-Header um.

Für GPU-Entwickler relevant: HIP-Code lässt sich jetzt für SPIR-V-Ziele kompilieren, etwa über das chipStar-Projekt. Auf der Kommandozeile gibt cmake --version =json-v1 detaillierte Versionsinformationen im JSON-Format aus, und cmake --build erlaubt es nun, Build-Verzeichnis und Preset gemeinsam anzugeben. Neue Generator-Expressions $ erweitern die Möglichkeiten für String-Operationen in Build-Skripten. Die Preset-Dateien unterstützen Schema-Version 11, und die File-Based API wurde auf Codemodel-Version 2.10 aktualisiert.

Neue Variablen CMAKE__LINK_FLAGS und CMAKE__LINK_FLAGS_ ermöglichen sprachspezifische Linker-Flags für alle Target-Typen. Einen vollständigen Überblick sämtlicher Änderungen in CMake 4.3 liefern die Release Notes. Die neue Version steht auf der offiziellen Download-Seite als Binärpaket für Windows, macOS und Linux zum Download bereit.


(map)



Source link

Verwandte Themen:
Weiterlesen

Entwicklung & Code

Wasmer stellt Edge.js vor: Node.js in WebAssembly-Sandbox


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

.

Das Unternehmen Wasmer, das hinter der gleichnamigen WebAssembly-Runtime steht, hat Edge.js veröffentlicht. Die quelloffene JavaScript-Runtime ist darauf spezialisiert, Node.js-Workloads auf sichere Weise in WebAssembly-Sandboxen auszuführen. Insbesondere für die Anwendungsfälle KI und Edge Computing soll sich Edge.js eignen.

Weiterlesen nach der Anzeige

Nicht zu verwechseln ist die neue JavaScript-Runtime Edge.js mit dem älteren .NET-Projekt Edge.js.


enterJS Integrate AI

enterJS Integrate AI

(Bild: Stone Story / stock.adobe.com)

Webanwendungen mit KI anreichern, sodass sie wirklich besser werden? Der Online-Thementag enterJS Integrate AI am 28. April 2026 zeigt, wie das geht. Frühbuchertickets und Gruppenrabatte sind im Online-Ticketshop verfügbar.

Edge.js für sichere Node.js-Anwendungen

Wie das Wasmer-Team die Beweggründe hinter der neuen Runtime erklärt, hat Node.js zwei Schwierigkeiten: Es ist an V8 als einzige JavaScript-Engine gebunden und kann Workloads nicht sicher ohne Containerisierung oder Hardwarevirtualisierung ausführen. Das haben auch andere Anbieter wie Deno oder Bun erkannt und eigene JavaScript-Runtimes entwickelt, doch Wasmer besitzt mit Edge.js nach eigenen Angaben die erste vollständig in einer Sandbox laufende Variante ohne Docker-Container.

Edge.js verwendet die Node-API (ehemals N-API) als Abstraktions-Layer, eine API für das Erstellen nativer Add-ons, die als Teil von Node.js gepflegt wird und die V8-Engine wegabstrahiert. Dadurch lassen sich in Edge.js auch JavaScriptCore und QuickJS als JavaScript-Engines einsetzen. Für das System-Call-Sandboxing kommt WASIX zum Einsatz, ein Superset des modularen System-Interfaces für WebAssembly namens WASI (WebAssembly System Interface).

Laut Wasmer setzt Edge.js auf die Kompatibilität mit Node.js 24 und kann alles ausführen, was auch Node.js ausführen kann – darunter alle entsprechenden Frameworks wie Next.js oder Astro. Derzeit ist Edge.js 5 fünf bis 20 Prozent langsamer als Node.js bei nativer Ausführung, und 30 Prozent langsamer bei vollem Sandboxing mit Wasmer. Auch die Start-up-Zeiten von Anwendungen sind langsamer als bei Node.js. An der Geschwindigkeit plant das Entwicklungsteam auf dem Weg zu Edge.js 1.0 zu arbeiten. Ein konkretes Ziel lautet, dass Edge.js für die meisten Workloads schneller sein soll als Bun oder Deno.

Weiterlesen nach der Anzeige

Per KI-Coding zu Edge.js

Das Wasmer-Team gibt an, für die Implementierung von Edge.js auf künstliche Intelligenz, hauptsächlich auf OpenAI GPT-5.4, zurückgegriffen zu haben. Ein kleineres Start-up wie Wasmer hätte ansonsten mindestens ein oder zwei Jahre für dieses Projekt gebraucht, statt lediglich weniger Wochen. Dank des KI-Coding-Agenten OpenAI Codex konnten sich demnach auch Developer im Team ohne Expertise in C++ oder Node.js beim Bugfixing einbringen.

Weitere Informationen zum initialen Edge.js-Release bietet der Wasmer-Blog.


(mai)



Source link

Weiterlesen

Entwicklung & Code

IntelliJ IDEA 2025.3.4 unterstützt Java 26 vollständig


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

.

Das Update der Entwicklungsumgebung IntelliJ IDEA 2025.3.4 von JetBrains unterstützt nun das am 17. März veröffentlichte Java 26 vollständig. Außerdem spendiert die Firma dem Agenten-Framework Koog eine Java-API.

Weiterlesen nach der Anzeige

Entwicklerinnen und Entwickler können nach dem Update mit allen zehn der großen Neuerungen von Java 26 arbeiten, mit den fünf stabilen, wie HTTP/3, und den fünf Previews, wie Pattern Matching mit Primitives.

Um Preview-Funktionen freizuschalten, stellt man die Sprachstufe in der IDE auf „Language level to 26 (Preview) – Primitive types in patterns (Fourth preview)“. Dann blendet IntelliJ alle Hilfen auch für diese Sprachstufe an, einschließlich Inspections and Quick-fixes ein. Bei den Preview-Funktionen zeigt das Tool zusätzlich einen Warnhinweis, da Anwender sie möglicherweise nicht in Code für die Produktion einsetzen möchten.

JetBrains unterstützt auch noch unreife Incubator-Funktionen von Java 26 wie die Verctor API. Zur Nutzung ist ein spezieller Schalter erforderlich: --add-modules jdk.incubator.vector.

Darüber hinaus gibt es kleinere Bugfixes und Verbesserungen in der IDE. Beispielsweise beseitigt das Update einen Fehler, der falsche HTTP-Requests auslöst; und der Tab für Dependencies in der Funktion Analyze Cyclic Dependencies öffnet sich nun richtig. Im DB-Explorer lassen sich jetzt Knoten von Abfragedateien verstecken und beim Language Server für Astro gibt es Verbesserungen im automatischen Vervollständigen.

Für den Einsatz von Java 26 ist das entsprechende JDK erforderlich. Das lässt sich direkt in IntelliJ oder mithilfe von Tools wie SDKMAN laden. Ebenfalls zum Download steht ein neuer Build von Project Valhalla. Das Update von IntelliJ lässt sich innerhalb der IDE mit der Toolbox installieren, über Ubuntu-Snaps oder von der Webseite laden.

Weiterlesen nach der Anzeige

Neu von JetBrains ist zudem eine Java-API für das Agenten-Framework Koog, die Zugriff auf alle Funktionen des ursprünglich rein für Kotlin entwickelten Frameworks bietet: Planung und Organisation von agentischen Workflows, alle größeren Modelle, Spring Boot oder Observability.

Ebenfalls ein Update gibt es für die Programmiersprache Kotlin 2.3.30, das ein neues Modell für die Nutzung der C-Bibliotheken bietet und kompatibel zu Gradle 9.3 ist.


(who)



Source link

Weiterlesen

Entwicklung & Code

Intel stellt Notebook-Topmodell Core Ultra 9 290HX Plus vor


Intel stellt die beiden Mobilprozessoren Core Ultra 9 290HX Plus und Core Ultra 7 270HX Plus vor. Sie gehören wie schon die Plus-Modelle für Desktop-PCs zur Baureihe Arrow Lake Refresh. Die Neuauflage für Notebooks ist nur logisch: Die HX-Prozessoren nutzen die gleichen Chips wie die Desktop-CPUs, Intel kann die Optimierungen also einfach übernehmen. Sie sind für High-End-Notebooks und mobile Workstations gedacht, für die es keine neueren Panther-Lake-Modelle gibt.

Weiterlesen nach der Anzeige

Die Notebook-Typen erhalten zwei Verbesserungen: Die Datenverbindung zwischen den Chiplets (Die-to-Die-Taktfrequenz) steigt von 2,1 auf 3,0 GHz. Zudem bietet Intel ein Binary Optimization Tool an, das in bestimmten Spielen und Anwendungen den Code für die Plus-Prozessoren optimiert. Der Hersteller sieht die Optimierungen ausschließlich für den Arrow Lake Refresh vor.


(Bild:

Intel

)

Intel zeigt Vergleichs-Benchmarks in 32 Spielen, die in Full-HD-Auflösung (1920 × 1080 Pixel) und hohen Grafikeinstellungen entstanden sind. Der Core Ultra 9 290HX Plus soll durchschnittlich acht Prozent schneller sein als das bisherige Topmodell Core Ultra 9 285HX. In 12 der 32 Spiele bringt das Binary Optimization Tool Vorteile. In Anwendungen nennt Intel einen Vorteil von sieben Prozent.


(Bild:

Intel

)

Die Produktseiten der neuen Prozessoren zeigen noch Unterschiede bei den Taktfrequenzen: Zwar können die Effizienzkerne in der Spitze minimal höher takten, jedoch sinkt der Basistakt der E-Kerne um 300 MHz auf 1,8 GHz. Bei den Performance-Kernen sinkt der Basistakt minimal, der maximale Turbo bleibt gleich. Der Core Ultra 9 290HX Plus schafft bis zu 5,5 GHz, der Core Ultra 7 270HX Plus 5,3 GHz.

Notebook-Hersteller können ab sofort Geräte mit dem Core Ultra 9 290HX Plus und Core Ultra 7 270HX Plus vorstellen. Zahlreiche Hersteller stellen bestehende Designs um.

Weiterlesen nach der Anzeige

Kein Desktop-290K-Plus

Für Desktop-PCs kommt derweil kein Core Ultra 9 290K Plus, weil Intel da weniger Spielraum für Verbesserungen hat. Schon der bereits erhältliche Core Ultra 9 285K hat mit dem 200S Boost eine erhöhte Die-to-Die-Taktfrequenz. Das Binary Optimization Tool allein rechtfertigt offenbar keine Neuauflage.


(mma)



Source link

Weiterlesen

Beliebt