【问题标题】:Eclipse CDT update/sync project list automatically (to easy "refresh" related project set)Eclipse CDT 自动更新/同步项目列表(方便“刷新”相关项目集)
【发布时间】:2016-10-01 19:40:51
【问题描述】:

历史背景:

我们有一个项目由以下部分组成:

  • 主机应用程序 (C++)
  • 脚本引擎库(也用 C++ 编写)
  • 很多 C++ 插件(大约 30+)
  • 许多脚本将所有内容联系在一起...

从一个版本到另一个版本,添加了一些插件,删除了一些插件。 到目前为止,我们使用 Visual Studio 解决方案 (*.sln) 来包含主机应用程序、脚本引擎库和插件的所有项目 (*.vcxproj)(每个插件一个 *.vcxproj!)。 为了共享源代码/项目,我们使用专有的源代码控制系统,直到现在我们合并了来自服务器的更新(添加了一些插件项目,删除了一些插件项目),由于“重新加载”功能,VS 中的所有项目树都被刷新了(开发人员无需执行任何操作即可查看和构建更新的源代码树)。

问题:

现在我们的高级管理人员决定改用 Eclipse CDT/MinGW 对,我们面临的问题是 Eclipse Workspace 与 Visual Studio *.sln 不同......

现在,当某些插件项目文件夹出现或某些插件项目文件夹消失时,相应的工作区项不会相应更新。

因此,从现在开始,每个开发人员都必须使用 File>Import...>General>"Existing projects into workspace" File/"Open Projects from File System" 手动将新项目添加到自己的 Workspace一旦它们被其他开发人员添加到源代码管理中。 还必须手动从自己的工作区中删除那些从源代码管理中删除的插件项目...

这与我们之前在 Visual Studio 中使用的“重新加载”功能自动更新项目/源代码树形成了鲜明对比(只是因为所有信息都来自 *.sln/*.vcxproj服务器)。

我们的第一个选择是将 Workspace\.metadata 等东西放到源代码控制中(就像我们之前对 *.sln 文件所做的那样),但是“这不是 Eclipse Workspace 的设计方式”(这甚至不是可能只是因为 .metadata\* 中的路径是绝对的,而且大量的 Workspace\* 东西根本无法合并)

问题:

是否有某种方法可以自动同步 Eclipse CDT Workspace 与从源代码控制获得的项目集。就像只需按下一些(隐藏的?)神奇的“刷新”按钮(在特殊插件中安装或类似的东西),所有新项目将自动添加到工作区的源代码树并删除项目也会自动消失,不需要使用所有那些“导入”向导,也不需要手动删除已删除的项目?

在 Eclipse 中可能有一个特殊的“容器”项目类型来扮演与 Visual Studio 中的 *.sln 或类似的角色相同的角色?

可能还有其他可用的选项吗?... 总体意图不是用一些 Eclipse 等效项替换 *.sln,而是在将一堆插件项目作为一个整体管理时支持类似的工作流程,并且 项目集“刷新”是一种简单的操作,不需要团队中的每个人手动跟踪该集中出现/消失的项目。

【问题讨论】:

    标签: c++ eclipse eclipse-cdt


    【解决方案1】:

    您是否考虑过使用 CMake 生成 Eclipse 项目文件?然后,您可以将它们导入 Eclipse 工作区。

    它不是自动的,但是如果您为每个部分创建单独的 CMakeLists.txt 文件,那么您可以轻松地在主 CMakeLists.txt 文件中注释该部分的包含,并在您只想加载项目文件的子集时重新生成项目文件项目。

    https://cmake.org/Wiki/Eclipse_CDT4_Generator

    如果您想改回 VS 或其他 IDE,CMake 也可以为此生成项目文件。

    我个人只使用 CMake 来生成 VS 解决方案和 Unix make 文件,所以我不能保证它的效果如何。

    HTH。


    附带说明,为什么管理 决定应该使用 Eclipse 而不是 Visual Studio?这听起来像是一个糟糕的决定,在做出决定之前没有事实依据或影响研究。

    是因为 Eclipse 是免费的吗?他们是否考虑过是什么降低了开发人员的生产力成本?

    【讨论】:

    • 你是绝对正确的,管理层决定使用 Eclipse 只是因为 Eclipse 是免费的,并且因为“与我们使用免费工具的其他团队相比,为什么你的团队享有特权”政治事情......我们推迟了迁移到 Eclipse 争论“降低开发人员生产力”的问题,但现在我们再次面临迁移问题。我喜欢 CMake 方法,但这仍然不能完全解决整个团队所看到的问题......
    猜你喜欢
    • 1970-01-01
    • 2014-12-14
    • 1970-01-01
    • 2018-08-29
    • 2018-08-21
    • 2010-11-02
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多