fix[tools][eclipse]: handle hidden directories in source exclusion

[wdfk-prog]

为什么提交这份PR (why to submit this PR)

当前 tools/targets/eclipse.py 在执行 scons --target=eclipse 生成 Eclipse/CDT 工程时，ExcludePaths() 会无条件跳过所有以 . 开头的隐藏目录：

if file.startswith('.'):
    continue

这会导致隐藏目录无法进入后续的 source exclusion 计算。

对于只包含配置文件的 .git、.vscode、.settings 等目录，这通常不会产生明显问题；但如果隐藏目录中存在可编译源文件，例如：

component/
├── SConscript
├── src/
└── .github/
    └── ci/
        ├── device-host-test.c
        └── lifecycle-host-test.c

而这些 *.c 文件并没有被对应 SConscript 加入目标固件构建，则原生 SCons 构建不会编译它们。

但是通过：

scons --target=eclipse

生成 Eclipse/CDT Managed Build 工程后，由于 .github 被 ExcludePaths() 直接跳过，没有加入 .cproject 的 excluding 列表，CDT 仍可能把其中的 *.c 文件识别为工程源码，并在 IDE Build 时进行目标平台编译。

实际使用中可以导致类似以下情况：

.github/ci/.../host-test.c

中的 Host Test stub 与真实 RT-Thread API 同时参与 ARM firmware 编译，从而出现：

conflicting types for 'rt_sem_init'
conflicting types for 'rt_mutex_take'
conflicting types for 'rt_thread_create'

等错误。

该问题并不局限于 .github。

类似：

.tests/
.ci/
.host/

等任何包含源代码的隐藏目录，只要没有参与实际目标构建，都可能遇到同样的问题。

因此这里需要修复的是 Eclipse source exclusion 对隐藏目录的一般处理逻辑，而不是对 .github 做特殊处理。

你的解决方案是什么 (what is your solution)

本 PR 修改 tools/targets/eclipse.py 中隐藏目录的 source exclusion 处理逻辑。

主要修改如下：

1. ExcludePaths() 不再无条件跳过所有以 . 开头的目录。

隐藏目录现在与普通目录使用相同的 exclusion 判断逻辑：

• 如果目录属于当前工程使用的目录，则继续递归分析；
• 如果目录不属于当前工程使用的目录，则作为 exclusion candidate 处理。

这样可以避免隐藏目录绕过 Eclipse source exclusion 计算。

2. CollectAllFilesinPath() 不再跳过所有隐藏目录。

原来的逻辑：

if item.startswith('.'):
    continue

会导致以下结构无法被检测：

unused/
└── .tests/
    └── host-test.c

本 PR 改为允许递归检查普通隐藏目录，从而能够正确检测其中是否存在：

*.c
*.cpp
*.cxx
*.cc
*.s
*.S
*.asm
*.cmd

等 Eclipse 可编译源文件。

3. 对源码版本控制元数据目录进行单独处理。

为避免递归扫描：

.git
.svn
.hg

等可能包含大量文件的版本控制元数据目录，增加：

scm_metadata_dirs = ('.git', '.svn', '.hg')

CollectAllFilesinPath() 不递归这些目录。

同时，如果这些目录已经被判定为 exclusion candidate，则直接加入 Eclipse exclusion，而不继续扫描其内部文件。

因此本次修改不会为了判断 .git 是否包含源文件而递归遍历 .git/objects 等目录。

最终行为为：

普通目录
    |
    +-- 参与工程 -> 按原有逻辑继续分析
    |
    +-- 未参与工程 -> 检查是否包含源代码并生成 exclusion

隐藏目录
    |
    +-- 参与工程 -> 按原有逻辑继续分析
    |
    +-- 未参与工程 -> 检查是否包含源代码并生成 exclusion

.git / .svn / .hg
    |
    +-- 未参与工程 -> 直接 exclusion，不递归扫描

本 PR 不修改原生 SCons firmware build 的源码选择逻辑，仅修复 scons --target=eclipse 生成的 Eclipse/CDT source exclusion 与实际工程源码选择不一致的问题。

请提供验证的bsp和config (provide the config and bsp)

• BSP:

  bsp/stm32/stm32f407-atk-explorer

• .config:

  本修改属于 Eclipse project generator 修复，不依赖额外 Kconfig 配置。

• action:

[github-actions]

👋 感谢您对 RT-Thread 的贡献！Thank you for your contribution to RT-Thread!

为确保代码符合 RT-Thread 的编码规范，请在你的仓库中执行以下步骤运行代码格式化工作流（如果格式化CI运行失败）。
To ensure your code complies with RT-Thread's coding style, please run the code formatting workflow by following the steps below (If the formatting of CI fails to run).

---

🛠 操作步骤 | Steps

1. 前往 Actions 页面 | Go to the Actions page
   点击进入工作流 → | Click to open workflow →

2. 点击 Run workflow | Click Run workflow

• Use workflow from 保持默认分支（通常为 master）
  Keep the default branch (usually master) in Use workflow from
• 在 branch 输入框填写 PR 分支 fix/eclipse-hidden-source-exclusion
  Enter PR branch fix/eclipse-hidden-source-exclusion in the branch field
• 设置需排除的文件/目录（目录请以"/"结尾）
  Set files/directories to exclude (directories should end with "/")

3. 等待工作流完成 | Wait for the workflow to complete
   格式化后的代码将作为独立提交推送至你的分支。
   The formatting changes will be pushed to your branch as a separate commit.

完成后，提交将自动更新至 fix/eclipse-hidden-source-exclusion 分支，关联的 Pull Request 也会同步更新。
Once completed, commits will be pushed to the fix/eclipse-hidden-source-exclusion branch automatically, and the related Pull Request will be updated.

如有问题欢迎联系我们，再次感谢您的贡献！💐
If you have any questions, feel free to reach out. Thanks again for your contribution!

[github-actions]

MemBrowse Memory Report

No memory changes detected for:

• at32f415-start
• esp32-c3
• gd32105r-start
• hc32f334
• hpmicro-hpm5301evklite
• infineon-psoc6
• k230
• loongson-ls1cdev
• nordic-nrf51822
• nuvoton-m487
• nxp-lpc1114
• qemu-virt64-aarch64
• raspberry-pico-rp2040
• renesas-ra2l1
• simulator
• stm32f407-rt-spark
• stm32l475-atk-pandora-llvm
• wch-ch32v208w-r0
• x86
• xuantie-e901plus

[Rbb666]

@wdfk-prog ci有错误了，麻烦检查下

[wdfk-prog]

@wdfk-prog ci有错误了，麻烦检查下

一、CI 失败的直接原因已经确认

我读取了 PR #11787 对应的 GitHub Actions Job 原始日志。

本次 CI 失败的直接原因是 Runner 无法找到 scons 命令，而不是 Eclipse 隐藏目录排除逻辑本身报错。

Tools / Project generate Tools

失败

Run 38119970063 · Job 114416188183 · 2026-10-11

关键日志：

Test to generate eclipse project

.../abba2362-4d59-46e3-a264-5a8fc7c339bd.sh:
line 2: scons: command not found

Error: Process completed with exit code 127.

另外，在前一个 Build Tools 步骤中，还有一条异常：

Error: the toolchain path (C:\Users\XXYYZZ)
is not exist, please check 'EXEC_PATH'
in path or rtconfig.py.

这属于两个不同层面的问题：

• scons: command not found：最终导致 Job 失败，退出码 127。
• C:\Users\XXYYZZ：工具链路径配置异常，但所在步骤仍被 GitHub Actions 判定为成功。

因此，当前 CI 尚未运行到能够验证 PR 中 ExcludePaths() 新逻辑是否正确的阶段。

二、根因分析：实际上有两处 CI 环境问题

核对 .github/workflows/action_tools.yml、RT-Thread Env 安装脚本和 tools/building.py 后，可以把问题定位到以下调用链。

Install Tools

下载 RT-Thread Env 2.0.2，首次激活时创建 Python venv，安装 SCons 4.11.1

Build Tools

执行 source ~/.env/env.sh，获得 SCons，但同时覆盖 RTT_EXEC_PATH；编译器路径检查报错

Project generate Tools

新 Shell 未激活 Python venv，scons 不在 PATH 中，直接退出 127

问题 A：Python 虚拟环境没有跨步骤保持

当前工作流只有 Build Tools 使用：

source ~/.env/env.sh

但是每个 GitHub Actions run 步骤都有独立的 Shell 进程。上一阶段修改的 PATH 不会自动传递到下一阶段。

因此 SCons 虽然已经安装，但后续步骤无法通过命令名找到它。

问题 B：Env 激活脚本覆盖了交叉编译器路径

这也是一个需要一起处理的地方。

工作流原先通过 $GITHUB_ENV 设置：

RTT_EXEC_PATH=/opt/gcc-arm-none-eabi-10-2020-q4-major/bin

但我查看了 RT-Thread Env 的 env.sh，其结尾包含：

export PATH="$ENV_SCRIPTS_ROOT:$PATH"
export RTT_EXEC_PATH=/usr/bin

第二条会覆盖工作流先前配置好的 ARM GCC 路径。

tools/building.py 随后执行编译器检测。如果当前路径找不到编译器，会删除 RTT_EXEC_PATH 并尝试自动检测；自动检测未找到可用工具链时，重新加载 rtconfig.py，便可能恢复其中的 Windows 默认路径：

EXEC_PATH = r'C:\Users\XXYYZZ'

这与日志中的工具链路径错误吻合。

而 tools/building.py 对该错误最终执行的是 exit(0)，因此 GitHub Actions 仍可能把有错误的 Build Tools 步骤标记为成功。

结论：仅在生成步骤添加 source ~/.env/env.sh 还不够，必须在激活 Env 后恢复正确的 RTT_EXEC_PATH。

三、建议修复方式

建议只修改工作流文件：

[ .github/workflows/action_tools.yml](https://github.com/RT-Thread/rt-thread/blob/6076a04b8d2a588862869afa98036a75258285f9/.github/workflows/action_tools.yml)

不需要为这次 CI 环境故障修改 tools/targets/eclipse.py。

1. 修复三个步骤的环境初始化

在 Build Tools、Project generate Tools、Project dist Tools 三个步骤的 run: 开头统一使用：

# Save the toolchain path configured by GITHUB_ENV.
toolchain_path="$RTT_EXEC_PATH"

# Activate RT-Thread Env and its Python virtual environment.
source "$HOME/.env/env.sh"

# Restore the ARM GCC path overridden by env.sh.
export RTT_EXEC_PATH="$toolchain_path"

# Verify the required tools.
command -v scons
test -x "$RTT_EXEC_PATH/arm-none-eabi-gcc"

其中 Build Tools 原来的 source ~/.env/env.sh 应替换为上述代码，不要重复激活。

这项修改同时解决：

• 新 Shell 找不到虚拟环境中的 SCons。
• Env 激活后交叉编译器路径被覆盖。

2. 防止构建错误被误判为成功

在 Build Tools 最后一次 scons -j$(nproc) 后增加：

test -f "$TEST_BSP_ROOT/rt-thread.elf"

因为当前 SConstruct 的目标文件是 rt-thread.elf，这个检查可以避免构建脚本打印错误、却返回退出码 0 时 CI 仍继续执行。

3. 长期修复 Env 脚本

RT-Thread Env 上游的 [env.sh](https://github.com/RT-Thread/env/blob/master/env.sh) 最好不要无条件覆盖已有的工具链配置。可以考虑将：

export RTT_EXEC_PATH=/usr/bin

改为：

export RTT_EXEC_PATH="${RTT_EXEC_PATH:-/usr/bin}"

这样调用方已经设置 RTT_EXEC_PATH 时，就不会被覆盖。但这是另一个仓库的修改，建议单独处理。

四、对 PR #11787 的影响

PR 当前只修改了 tools/targets/eclipse.py，而本次 CI 中：

• Eclipse 工程生成测试尚未真正执行。
• PR 的隐藏目录处理逻辑尚未得到 CI 验证。
• 现有失败证据指向工作流与 Env 的环境管理，而非 PR 源码逻辑。

建议优先修复工作流，再重新触发 ToolsCI，确认 BSP 编译、Eclipse/CMake/Makefile 工程生成及 dist 测试是否成功。

执行状态： 已完成远端日志、PR Diff、工作流及相关源码的只读检查，根因已定位；未修改 PR、未执行远端重跑，多轮 Review 未执行。

参考源码：[CI 工作流](https://github.com/RT-Thread/rt-thread/blob/6076a04b8d2a588862869afa98036a75258285f9/.github/workflows/action_tools.yml) · [工具链路径检测逻辑](

rt-thread/tools/building.py

Lines 246 to 278 in 6076a04

	# auto change the 'RTT_EXEC_PATH' when 'rtconfig.EXEC_PATH' get failed
	if not utils.CmdExists(os.path.join(rtconfig.EXEC_PATH, rtconfig.CC)):
	Env['log'].debug('To detect CC because CC path in rtconfig.py is invalid:')
	Env['log'].debug(' rtconfig.py cc ->' + os.path.join(rtconfig.EXEC_PATH, rtconfig.CC))
	if 'RTT_EXEC_PATH' in os.environ:
	# del the 'RTT_EXEC_PATH' and using the 'EXEC_PATH' setting on rtconfig.py
	del os.environ['RTT_EXEC_PATH']
	try:
	# try to detect toolchains in env
	envm = utils.ImportModule('env_utility')
	# from env import GetSDKPath
	exec_path = envm.GetSDKPath(rtconfig.CC)
	if exec_path != None:
	if 'gcc' in rtconfig.CC:
	exec_path = os.path.join(exec_path, 'bin')
	if os.path.exists(exec_path):
	Env['log'].debug('set CC to ' + exec_path)
	rtconfig.EXEC_PATH = exec_path
	os.environ['RTT_EXEC_PATH'] = exec_path
	else:
	Env['log'].debug('No Toolchain found in path(%s).' % exec_path)
	except Exception as e:
	# detect failed, ignore
	Env['log'].debug(e)
	pass
	exec_path = GetOption('exec-path')
	if exec_path:
	os.environ['RTT_EXEC_PATH'] = exec_path
	utils.ReloadModule(rtconfig) # update environment variables to rtconfig.py

) · [构建异常退出逻辑](https://github.com/RT-Thread/rt-thread/blob/6076a04b8d2a588862869afa98036a75258285f9/tools/building.py#L1067-L1073)。

[Rbb666]

@wdfk-prog ci有错误了，麻烦检查下

一、CI 失败的直接原因已经确认

我读取了 PR #11787 对应的 GitHub Actions Job 原始日志。

本次 CI 失败的直接原因是 Runner 无法找到 scons 命令，而不是 Eclipse 隐藏目录排除逻辑本身报错。

Tools / Project generate Tools

失败

Run 38119970063 · Job 114416188183 · 2026-10-11

关键日志：

Test to generate eclipse project

.../abba2362-4d59-46e3-a264-5a8fc7c339bd.sh:
line 2: scons: command not found

Error: Process completed with exit code 127.

另外，在前一个 Build Tools 步骤中，还有一条异常：

Error: the toolchain path (C:\Users\XXYYZZ)
is not exist, please check 'EXEC_PATH'
in path or rtconfig.py.

这属于两个不同层面的问题：

• scons: command not found：最终导致 Job 失败，退出码 127。
• C:\Users\XXYYZZ：工具链路径配置异常，但所在步骤仍被 GitHub Actions 判定为成功。

因此，当前 CI 尚未运行到能够验证 PR 中 ExcludePaths() 新逻辑是否正确的阶段。

二、根因分析：实际上有两处 CI 环境问题

核对 .github/workflows/action_tools.yml、RT-Thread Env 安装脚本和 tools/building.py 后，可以把问题定位到以下调用链。

Install Tools

下载 RT-Thread Env 2.0.2，首次激活时创建 Python venv，安装 SCons 4.11.1

Build Tools

执行 source ~/.env/env.sh，获得 SCons，但同时覆盖 RTT_EXEC_PATH；编译器路径检查报错

Project generate Tools

新 Shell 未激活 Python venv，scons 不在 PATH 中，直接退出 127

问题 A：Python 虚拟环境没有跨步骤保持

当前工作流只有 Build Tools 使用：

source ~/.env/env.sh

但是每个 GitHub Actions run 步骤都有独立的 Shell 进程。上一阶段修改的 PATH 不会自动传递到下一阶段。

因此 SCons 虽然已经安装，但后续步骤无法通过命令名找到它。

问题 B：Env 激活脚本覆盖了交叉编译器路径

这也是一个需要一起处理的地方。

工作流原先通过 $GITHUB_ENV 设置：

RTT_EXEC_PATH=/opt/gcc-arm-none-eabi-10-2020-q4-major/bin

但我查看了 RT-Thread Env 的 env.sh，其结尾包含：

export PATH="$ENV_SCRIPTS_ROOT:$PATH"
export RTT_EXEC_PATH=/usr/bin

第二条会覆盖工作流先前配置好的 ARM GCC 路径。

tools/building.py 随后执行编译器检测。如果当前路径找不到编译器，会删除 RTT_EXEC_PATH 并尝试自动检测；自动检测未找到可用工具链时，重新加载 rtconfig.py，便可能恢复其中的 Windows 默认路径：

EXEC_PATH = r'C:\Users\XXYYZZ'

这与日志中的工具链路径错误吻合。

而 tools/building.py 对该错误最终执行的是 exit(0)，因此 GitHub Actions 仍可能把有错误的 Build Tools 步骤标记为成功。

结论：仅在生成步骤添加 source ~/.env/env.sh 还不够，必须在激活 Env 后恢复正确的 RTT_EXEC_PATH。

三、建议修复方式

建议只修改工作流文件：

[ .github/workflows/action_tools.yml](https://github.com/RT-Thread/rt-thread/blob/6076a04b8d2a588862869afa98036a75258285f9/.github/workflows/action_tools.yml)

不需要为这次 CI 环境故障修改 tools/targets/eclipse.py。

1. 修复三个步骤的环境初始化

在 Build Tools、Project generate Tools、Project dist Tools 三个步骤的 run: 开头统一使用：

# Save the toolchain path configured by GITHUB_ENV.
toolchain_path="$RTT_EXEC_PATH"

# Activate RT-Thread Env and its Python virtual environment.
source "$HOME/.env/env.sh"

# Restore the ARM GCC path overridden by env.sh.
export RTT_EXEC_PATH="$toolchain_path"

# Verify the required tools.
command -v scons
test -x "$RTT_EXEC_PATH/arm-none-eabi-gcc"

其中 Build Tools 原来的 source ~/.env/env.sh 应替换为上述代码，不要重复激活。

这项修改同时解决：

• 新 Shell 找不到虚拟环境中的 SCons。
• Env 激活后交叉编译器路径被覆盖。

2. 防止构建错误被误判为成功

在 Build Tools 最后一次 scons -j$(nproc) 后增加：

test -f "$TEST_BSP_ROOT/rt-thread.elf"

因为当前 SConstruct 的目标文件是 rt-thread.elf，这个检查可以避免构建脚本打印错误、却返回退出码 0 时 CI 仍继续执行。

3. 长期修复 Env 脚本

RT-Thread Env 上游的 [env.sh](https://github.com/RT-Thread/env/blob/master/env.sh) 最好不要无条件覆盖已有的工具链配置。可以考虑将：

export RTT_EXEC_PATH=/usr/bin

改为：

export RTT_EXEC_PATH="${RTT_EXEC_PATH:-/usr/bin}"

这样调用方已经设置 RTT_EXEC_PATH 时，就不会被覆盖。但这是另一个仓库的修改，建议单独处理。

四、对 PR #11787 的影响

PR 当前只修改了 tools/targets/eclipse.py，而本次 CI 中：

• Eclipse 工程生成测试尚未真正执行。
• PR 的隐藏目录处理逻辑尚未得到 CI 验证。
• 现有失败证据指向工作流与 Env 的环境管理，而非 PR 源码逻辑。

建议优先修复工作流，再重新触发 ToolsCI，确认 BSP 编译、Eclipse/CMake/Makefile 工程生成及 dist 测试是否成功。

执行状态： 已完成远端日志、PR Diff、工作流及相关源码的只读检查，根因已定位；未修改 PR、未执行远端重跑，多轮 Review 未执行。

参考源码：[CI 工作流](https://github.com/RT-Thread/rt-thread/blob/6076a04b8d2a588862869afa98036a75258285f9/.github/workflows/action_tools.yml) · [工具链路径检测逻辑](

rt-thread/tools/building.py

Lines 246 to 278 in 6076a04

	# auto change the 'RTT_EXEC_PATH' when 'rtconfig.EXEC_PATH' get failed
	if not utils.CmdExists(os.path.join(rtconfig.EXEC_PATH, rtconfig.CC)):
	Env['log'].debug('To detect CC because CC path in rtconfig.py is invalid:')
	Env['log'].debug(' rtconfig.py cc ->' + os.path.join(rtconfig.EXEC_PATH, rtconfig.CC))
	if 'RTT_EXEC_PATH' in os.environ:
	# del the 'RTT_EXEC_PATH' and using the 'EXEC_PATH' setting on rtconfig.py
	del os.environ['RTT_EXEC_PATH']
	try:
	# try to detect toolchains in env
	envm = utils.ImportModule('env_utility')
	# from env import GetSDKPath
	exec_path = envm.GetSDKPath(rtconfig.CC)
	if exec_path != None:
	if 'gcc' in rtconfig.CC:
	exec_path = os.path.join(exec_path, 'bin')
	if os.path.exists(exec_path):
	Env['log'].debug('set CC to ' + exec_path)
	rtconfig.EXEC_PATH = exec_path
	os.environ['RTT_EXEC_PATH'] = exec_path
	else:
	Env['log'].debug('No Toolchain found in path(%s).' % exec_path)
	except Exception as e:
	# detect failed, ignore
	Env['log'].debug(e)
	pass
	exec_path = GetOption('exec-path')
	if exec_path:
	os.environ['RTT_EXEC_PATH'] = exec_path
	utils.ReloadModule(rtconfig) # update environment variables to rtconfig.py

) · [构建异常退出逻辑](https://github.com/RT-Thread/rt-thread/blob/6076a04b8d2a588862869afa98036a75258285f9/tools/building.py#L1067-L1073)。%E3%80%82)

关联：#11863