Set CC and CXX environment variables for clang toolchain #1169

betamaxbandit · 2025-05-27T22:51:29Z

Sets the C and C++ compiler environment variables so CMake uses Clang instead of the system default compiler.

betamaxbandit · 2025-05-27T22:52:43Z

Thanks to @Kummallinen for the suggestion to set cc environment variables.

I'll update this soon with details of how to test.

jld01 · 2025-05-28T05:38:44Z

build/org.eclipse.cdt.build.gcc.core/src/org/eclipse/cdt/build/gcc/core/ClangToolChain.java

Using environment variables to select the compiler type will not be portable to other IDEs or to a CI build. So a core build project that builds with clang in CDT would build with gcc elsewhere unless equivalent environment variables are present. Is there an alternative that would preserve portability?

I agree. One of the strongest arguments against Eclipse CDT is that "we can't build your project without using your IDE.".

I'm not sure I see a portability problem here. If the users CMake file needs a particular compiler to build they can set that in the CMake file and this won't interfere with it. The environment variables are to select the compiler for a CMake project which is compiler agnostic (fairly common case) without needing to create a toolchain file when one isn't needed.

Additional point, in CI you'd likely just set the same environment variables in the docker container or CI pipeline used for build to nudge CMake into selecting Clang not GCC. This is generic CMake usage, nothing novel for Core Build

For reference, setting these variables is the 1st way the CMake Wiki suggests to do this: https://gitlab.kitware.com/cmake/community/-/wikis/FAQ#method-1-use-environment-variables.

Setting these does not stop the user doing it another way if they are using a different generator value for example & won't override anything the user sets in their toolchain, cmake files or customised command line.

The environment variables are to select the compiler for a CMake project which is compiler agnostic (fairly common case) without needing to create a toolchain file when one isn't needed.

I don't think the end user will necessarily appreciate a distinction like this. All they observe is a toolchain selection UI which gives the impression that they can select the toolchain (both path and compiler name) that applies to the project.

If it is common practice for developers using CMake to rely on environment to select toolchain technology (gcc or clang) in the absence of a toolchain file, then perhaps we just need to clarify within the UI that the selection applies within the Eclipse IDE only and may be overriden by directives in CMakeLists.txt, by CMake command line arguments or by toolchain file association.

If it is common practice for developers using CMake to rely on environment to select toolchain technology (gcc or clang) in the absence of a toolchain file, then perhaps we just need to clarify within the UI that the selection applies within the Eclipse IDE only and may be overriden by directives in CMakeLists.txt, by CMake command line arguments or by toolchain file association.

This is very common and is intended by the CMake developers. From what I've seen toolchain files are typically used when cross-compiling as the system name & architecture also need to be set along with other settings such as a sysroot. Though those can also come from environment variables.

A warning in the UI that the toolchain may be overridden by any custom arguments the user sets or within the CMake file itself would make sense. It also applies to the current state without this change as well.

If we set CC for clang, should we also set it for gcc in GCCToolChain? Otherwise we introduce the opposite problem. This is less common, but the same issue happens in reverse if cc is actually clang, like this:

$ readlink -f `which cc` /usr/lib/llvm-20/bin/clang

Yes I agree.
I have tested this and can reproduce the problem:

In a windows cmd shell,
set CC=clang
set CXX=clang++
Then launch eclipse CDT from this shell.
In a CMake project, in Build Settings, set Toolchain to:
C:\msys64\ucrt64\bin\gcc.exe
Build project.
Expected: Builds using gcc.
Actual: Builds using clang, eg:
"-- The C compiler identification is Clang 19.1.7
-- The CXX compiler identification is Clang 19.1.7
"

betamaxbandit · 2025-05-29T09:32:38Z

build/org.eclipse.cdt.build.gcc.core/src/org/eclipse/cdt/build/gcc/core/ClangToolChain.java

+		 * set(CMAKE_C_COMPILER clang)
+		 * set(CMAKE_CXX_COMPILER clang++)
+		 */
+		addIfAbsent("cc", "clang", envVarsNew); //$NON-NLS-1$ //$NON-NLS-2$


cc and cxx should be upper case!

Does envVarsNew already include the system environment, or is it just the environment set by other parts of Core Build? If it includes the system environment then we cant use addIfAbsent as they will likely already be set if you're on Linux or macOS

Does envVarsNew already include the system environment,

No; its the env from the core build and/or any env vars set by the user for a "User Defined Toolchain".

jld01 · 2025-05-30T11:55:33Z

build/org.eclipse.cdt.build.gcc.core/src/org/eclipse/cdt/build/gcc/core/ClangToolChain.java

+	private static IEnvironmentVariable[] addClangEnvVars(IEnvironmentVariable[] envVars) {
+		List<IEnvironmentVariable> envVarsNew = new ArrayList<>(Arrays.asList(envVars));
+		/*
+		 * Set CC and CXX environment variables for clang and clang++. This is equivalent to setting these in the


Do we also need to set the ASM environment variable?

Do we also need to set the ASM environment variable?

Good question. I do not think so. CMake appears to set ASM automatically to clang when CC is set to clang.

I tested this using the attached project.
cmakeASM.zip

In the screendshot below, it can be seen that the ASM is set to clang.exe.

Sets the C and C++ compiler environment variables so CMake uses Clang instead of the system default compiler. Fixes eclipse-cdt#1140

betamaxbandit · 2025-06-02T16:52:37Z

Tests

Test cases
A) Toolchain set to clang, causes the clang compiler to be used automatically.
B) Toolchain set to gcc, uses the default gcc compiler automatically.
Tests should be performed on Linux & Windows.

Prerequisites
Make sure cmake, make and ninja and multiple toolchains are installed on the host, including clang. See [1].

To test
Test Case A) Toolchain set to clang, causes the clang compiler to be used automatically.
Create a CMake Hello World project
From the Launch Bar, open the Launch Configuration (gear icon)
Select Build Settings tab and in the Toolchain dropdown, change to clang toolchain and click OK.
From the Launch Bar, build the project.
Expected: The project builds successfully and in the Console build output it can be seen that the C and CXX compiler are identified as "Clang".

The following shows an example of Console build output:

Configuring in: C:\Users\a5107948\cdt-main20250110b\runtime-cdtruntime_clean\cmake_hw\build\cmake.debug.win32.x86_64.Local
cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -G Ninja C:\Users\a5107948\cdt-main20250110b\runtime-cdtruntime_clean\cmake_hw
-- The C compiler identification is Clang 19.1.7
-- The CXX compiler identification is Clang 19.1.7
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/msys64/ucrt64/bin/clang.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/msys64/ucrt64/bin/clang++.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done (3.1s)
-- Generating done (0.1s)
-- Build files have been written to: C:/Users/a5107948/cdt-main20250110b/runtime-cdtruntime_clean/cmake_hw/build/cmake.debug.win32.x86_64.Local
Building in: C:\Users\a5107948\cdt-main20250110b\runtime-cdtruntime_clean\cmake_hw\build\cmake.debug.win32.x86_64.Local
cmake --build . --target all
[1/2] Building CXX object CMakeFiles/cmake_hw.dir/cmake_hw.cpp.obj
[2/2] Linking CXX executable cmake_hw.exe
Build complete (0 errors, 0 warnings): C:\Users\a5107948\cdt-main20250110b\runtime-cdtruntime_clean\cmake_hw\build\cmake.debug.win32.x86_64.Local

Test case B) Toolchain set to gcc, uses the default gcc compiler automatically.
Continuing from test above, open the Build Settings tab and change the toolchain to gcc and click OK.
Delete the project's build folder.
From the Launch Bar, build the project.
Expected: The project builds successfully and in the Console build output it can be seen that the C and CXX compiler are identified as "GNU".

The following shows an example of Console build output:

Configuring in: C:\Users\a5107948\cdt-main20250110b\runtime-cdtruntime_clean\cmake_hw\build\cmake.debug.win32.x86_64.Local
cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -G Ninja C:\Users\a5107948\cdt-main20250110b\runtime-cdtruntime_clean\cmake_hw
-- The C compiler identification is GNU 14.2.0
-- The CXX compiler identification is GNU 14.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/msys64/ucrt64/bin/cc.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/msys64/ucrt64/bin/c++.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done (3.2s)
-- Generating done (0.1s)
-- Build files have been written to: C:/Users/a5107948/cdt-main20250110b/runtime-cdtruntime_clean/cmake_hw/build/cmake.debug.win32.x86_64.Local
Building in: C:\Users\a5107948\cdt-main20250110b\runtime-cdtruntime_clean\cmake_hw\build\cmake.debug.win32.x86_64.Local
cmake --build . --target all
[1/2] Building CXX object CMakeFiles/cmake_hw.dir/cmake_hw.cpp.obj
[2/2] Linking CXX executable cmake_hw.exe
Build complete (0 errors, 0 warnings): C:\Users\a5107948\cdt-main20250110b\runtime-cdtruntime_clean\cmake_hw\build\cmake.debug.win32.x86_64.Local

[1]: Before you begin
C/C++ Development User Guide > Before you begin
https://github.com/eclipse-cdt/cdt/blob/abe4d1b8e16b03ceafbeb25f063cb728c7487862/doc/org.eclipse.cdt.doc.user/concepts/cdt_c_before_you_begin.htm

jonahgraham · 2025-06-05T14:04:28Z

build/org.eclipse.cdt.build.gcc.core/src/org/eclipse/cdt/build/gcc/core/ClangToolChain.java

+	 * However, on Windows, existing cc/cxx envVars with lower-case names will have their names changed to upper case;
+	 * the value remains unchanged.<br>


Why do this - can you simply use same logic as on Linux? See code comment for why I am asking the question

In our meeting on Th 5 Jun, we discussed this and agreed on windows any lower case cc/cxx env vars should be changed to upper case.
Do you no longer think that is a good idea?

Otherwise, yes, the same logic as used on Linux can be used for Windows.

jonahgraham · 2025-06-05T14:07:44Z

build/org.eclipse.cdt.build.gcc.core/src/org/eclipse/cdt/build/gcc/core/ClangToolChain.java

+						iterator.remove();
+						envVars.add(new EnvironmentVariable(name, evOldValue));


Goes with comment on line 73 and I have a suggestion attached to line 81-111

When you do the remove + add you may be changing the type and logic of the variable. The removed one may not be an EnvironmentVariable but one of the other implementations of of IEnvironmentVariable

Yes I see that now. Renaming the variable name is tricky. Perhaps we should forget about it.

jonahgraham · 2025-06-05T14:15:03Z

build/org.eclipse.cdt.build.gcc.core/src/org/eclipse/cdt/build/gcc/core/ClangToolChain.java

+		if (Platform.OS_WIN32.equals(Platform.getOS())) {
+			// On Windows: case-insensitive check ignores case.
+			Iterator<IEnvironmentVariable> iterator = envVars.iterator();
+			boolean found = false;
+
+			while (iterator.hasNext()) {
+				IEnvironmentVariable ev = iterator.next();
+				if (ev.getName().equalsIgnoreCase(name)) {
+					found = true;
+					// Replace if existing name is in lower-case and new name is in upper-case
+					if (!ev.getName().equals(name) && name.equals(name.toUpperCase())) {
+						// Original value is respected.
+						String evOldValue = ev.getValue();
+						iterator.remove();
+						envVars.add(new EnvironmentVariable(name, evOldValue));
+					}
+					break;
+				}
+			}
+
+			if (!found) {
+				envVars.add(new EnvironmentVariable(name, value));
+			}
+
+		} else {
+			// On non-Windows: case-sensitive check respects case (exact match).
+			boolean isAbsent = envVars.stream().noneMatch(ev -> ev.getName().equals(name));
+			if (isAbsent) {
+				envVars.add(new EnvironmentVariable(name, value));
+			}
+		}


Suggested change

if (Platform.OS_WIN32.equals(Platform.getOS())) {

// On Windows: case-insensitive check ignores case.

Iterator<IEnvironmentVariable> iterator = envVars.iterator();

boolean found = false;

while (iterator.hasNext()) {

IEnvironmentVariable ev = iterator.next();

if (ev.getName().equalsIgnoreCase(name)) {

found = true;

// Replace if existing name is in lower-case and new name is in upper-case

if (!ev.getName().equals(name) && name.equals(name.toUpperCase())) {

// Original value is respected.

String evOldValue = ev.getValue();

iterator.remove();

envVars.add(new EnvironmentVariable(name, evOldValue));

}

break;

}

}

if (!found) {

envVars.add(new EnvironmentVariable(name, value));

}

} else {

// On non-Windows: case-sensitive check respects case (exact match).

boolean isAbsent = envVars.stream().noneMatch(ev -> ev.getName().equals(name));

if (isAbsent) {

envVars.add(new EnvironmentVariable(name, value));

}

}

boolean isAbsent = envVars.stream().noneMatch(ev -> {

if (Platform.OS_WIN32.equals(Platform.getOS())) {

return ev.getName().equalsIgnoreCase(name);

} else {

return ev.getName().equals(name);

}

});

if (isAbsent) {

envVars.add(new EnvironmentVariable(name, value));

}

jonahgraham · 2025-06-05T14:45:31Z

build/org.eclipse.cdt.build.gcc.core/src/org/eclipse/cdt/build/gcc/core/ClangToolChain.java

If we set CC for clang, should we also set it for gcc in GCCToolChain? Otherwise we introduce the opposite problem. This is less common, but the same issue happens in reverse if cc is actually clang, like this:

$ readlink -f `which cc` /usr/lib/llvm-20/bin/clang

jld01 reviewed May 28, 2025

View reviewed changes

betamaxbandit commented May 29, 2025

View reviewed changes

jld01 reviewed May 30, 2025

View reviewed changes

Set CC and CXX environment variables for clang toolchain

680f662

Sets the C and C++ compiler environment variables so CMake uses Clang instead of the system default compiler. Fixes eclipse-cdt#1140

betamaxbandit force-pushed the clang_1140 branch from fb47754 to 680f662 Compare June 2, 2025 16:27

jonahgraham reviewed Jun 5, 2025

View reviewed changes

		* However, on Windows, existing cc/cxx envVars with lower-case names will have their names changed to upper case;
		* the value remains unchanged.<br>

		iterator.remove();
		envVars.add(new EnvironmentVariable(name, evOldValue));

Set CC and CXX environment variables for clang toolchain #1169

Are you sure you want to change the base?

Set CC and CXX environment variables for clang toolchain #1169

Uh oh!

Conversation

betamaxbandit commented May 27, 2025

Uh oh!

betamaxbandit commented May 27, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Kummallinen May 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

betamaxbandit Jun 2, 2025 • edited by jonahgraham Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

betamaxbandit Jun 2, 2025 • edited by jonahgraham Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

betamaxbandit commented Jun 2, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Kummallinen May 28, 2025 •

edited

Loading

betamaxbandit Jun 2, 2025 •

edited by jonahgraham

Loading

betamaxbandit Jun 2, 2025 •

edited by jonahgraham

Loading