Add CDT core native API bundle for compilation

[laeubi]

This is required for

• Add support for launching Eclipse Process in a system terminal session eclipse.platform#1762

currently it contains the cdt-main, but probably should reference the M2 repo (where relevant API was added) or a future CDT release.

Even though the bundle is named cdt it actually depends on nothing than JNA, therefore it can be used without really depend on CDT releases like any other API bundle (we just can't depend on new API if such would be ever added).

In a product one then would need to include the terminal feature (that includes the API and native fragments) to actually use the terminal console feature of platform.

FYI @merks @jonahgraham @akurtakov @stbischof

[laeubi]

currently it contains the cdt-main, but probably should reference the M2 repo (where relevant API was added) or a future CDT release.

Now changed it to RC2 (what is what CDT currently contributes to simrel at the moment).

[laeubi]

Adjusted with final CDT release.

[eclipse-platform-bot]

This pull request changes some projects for the first time in this development cycle.
Therefore the following files need a version increment:

eclipse.platform.releng/features/org.eclipse.test-feature/feature.xml

An additional commit containing all the necessary changes was pushed to the top of this PR's branch. To obtain these changes (for example if you want to push more changes) either fetch from your fork or apply the git patch.

Git patch

From ad5d1fe9442a7c1c3f46efade3a232e5f5113630 Mon Sep 17 00:00:00 2001
From: Eclipse Platform Bot <[email protected]>
Date: Fri, 13 Jun 2025 03:58:36 +0000
Subject: [PATCH] Version bump(s) for 4.37 stream


diff --git a/eclipse.platform.releng/features/org.eclipse.test-feature/feature.xml b/eclipse.platform.releng/features/org.eclipse.test-feature/feature.xml
index d73ef13960..f6e97cb6b2 100644
--- a/eclipse.platform.releng/features/org.eclipse.test-feature/feature.xml
+++ b/eclipse.platform.releng/features/org.eclipse.test-feature/feature.xml
@@ -2,7 +2,7 @@
 <feature
       id="org.eclipse.test"
       label="%featureName"
-      version="3.9.200.qualifier"
+      version="3.9.300.qualifier"
       provider-name="%providerName"
       license-feature="org.eclipse.license"
       license-feature-version="0.0.0">
-- 
2.49.0

Further information are available in Common Build Issues - Missing version increments.

[akurtakov]

I guess this is first step before moving it to platform so CDT doesn't have to become a -1 project ? @jonahgraham Are you fine with releasing CDT 1 week before each Platform M/RC ?

[laeubi]

As long as we do not add new API (or more formally use that new API at platform), one won't need to update this in any way, this is more like Junit or any other dependecy, we use it and might update it when a new version become available, but it is not mandatory to update.

Only for EPPs they might include latest CDT Terminal as its already the case.

[akurtakov]

The problem is the other way around what if CDT changes the bundle after RC2 release ?

[laeubi]

That's theoretically possible, but if you look at the history of both APIs we use (pty + spawner) these have not changed for years (beside some bugfixes/enhancements) except the additional method I added recently for the platform use-case, so I'm quite confident @jonahgraham might inform us in-time and not completely change everything after RC2 :-)

[merks]

For any given 3rd party bundle x, the Platform doesn't include them in any feature and the dependencies (in bundles) specify a range, so it's always possible that some installation will contain a newer version of x than the one the Platform tested against. This might even happen for bundles pulled directly from Maven because a newer one might be available after the Platform's RC2 but before the rest of the train's RC2. In SimRel, generally the highest version permitted by all the dependency ranges is what will be aggregated.

[jonahgraham]

I agree with what @laeubi says - these things haven't changed in a long time. And I am happy to accommodate @akurtakov request as follows: If there are any changes that may affect Platforms consumption of these bundles then CDT will publish as a -1 for that change.

xref new releasing documentation for CDT in eclipse-cdt/cdt#1190

[merks]

One thing to note though is that when the platform shuts down after the final RC2 build, the target platform contains permanent released update sites, including for ecf, emf, and orbit, so that the branch can be built in the future. I don’t that you’re committing to producing the cdt release before the platform. Of course I don’t think it’s a big deal to commit the final cdt repo to the tp in the release and master branches when it’s available given only this one bundle is consumed from it and given we don’t plan to change it during the rc phase, but it is an additional step we should keep in mind and handle accordingly.

[chirontt]

It looks like there's no terminal native fragment for Linux riscv64 in CDT. Yet the Eclipse SDKs (and EPP too) have builds for Linux riscv64 platform.

Is there a plan to add this riscv64 native fragment soon?

[merks]

I was wondering about the fragments but didn’t find them when I looked. What is the id of such a fragment? If such a thing is needed for riscv64, it would be good to contribute to CDT whatever is needed.

[chirontt]

It should be like the following in its manifest (i.e. similar to the existing Linux x86_64 native fragment):

Bundle-SymbolicName: org.eclipse.cdt.core.linux.riscv64;singleton:=true
Bundle-Version: 12.2.0.qualifier
Fragment-Host: org.eclipse.cdt.core.native;bundle-version="[6.3.0,7.0.0)"
Eclipse-PlatformFilter: (&(osgi.os=linux)(osgi.arch=riscv64))

Perhaps I should whip up a PR for such new terminal native fragment for riscv64...

[laeubi]

@chirontt as mentioned by @merks contributions in this area has to go to CDT for the moment. In general if the usual Terminal View in the EPP works it should work here as well.

Beside that there are two ways:

1. As you mentioned, one might create a new native fragment, that would probably require some (cross) compilation and some setup to actually publish this new project
2. One could use JNA for the relevant parts and make the code independent from an actual binary, this would be the best solution as it would cover other architectures as well and would allow us to easier migrate the code to platform directly. Sadly there is no tool I know about at the moment to automate such process.

[laeubi]

I now added a short introduction here:

https://github.com/eclipse-platform/www.eclipse.org-eclipse/blob/master/news/4.37/platform.md

[jonahgraham]

Perhaps I should whip up a PR for such new terminal native fragment for riscv64...

Yes please. See eclipse-cdt/cdt#980