如何在外部服务器上安装和使用嵌入式C的编译器？

概述简短的问题 是否有可接受的方法在远程服务器上运行嵌入式软件项目的编译器/链接器,并且仍然能够在本地计算机上编程和调试软件. 注意我知道每个IDE都会有所不同,所以我想要的是如何定义工作流来完成这个任务,假设可以使用从远程服务器构建的.o / .elf文件来运行IDE. 关注的领域 1)与虚拟Windows机器的联网. 2)如何/何时将源代码传输到服务器进行构建. 背景 我们的软件团队使用的每个微处 简短的问题
是否有可接受的方法在远程服务器上运行嵌入式软件项目的编译器/链接器,并且仍然能够在本地计算机上编程和调试软件.

注意我知道每个IDE都会有所不同,所以我想要的是如何定义工作流来完成这个任务,假设可以使用从远程服务器构建的.o / .elf文件来运行IDE.

关注的领域
1)与虚拟Windows机器的联网.
2)如何/何时将源代码传输到服务器进行构建.

背景
我们的软件团队使用的每个微处理器系列都需要它自己的编译器,IDE和编程器.加班加点带来许多难以克服的困难.

1)每个开发人员都需要自己的,通常是昂贵的许可证.
2)要获取另一个开发人员启动的项目需要格外小心,以确保所有编译器设置都相同.
3)支持遗留软件可能需要与当前安装的编译器冲突的旧编译器.
……列表一直在继续.

编辑：7-10-2011 1:30 PM CST
1)我所说的编译器确实是交叉编译器
2)该系统理想情况下支持的处理器系列的简短列表：Motorola Coldfire,PIC和STM8.
3)我们的Coldfire编译器是GCC的变体,但我们必须支持它的多个版本.所有其他编译器使用不提供浮动许可证的目标特定编译器.
4)为了解决littleadv问题,我想要完成的是外部构建服务器.
5)我们目前使用托管在在线存储库上的SVN和GIT的组合来进行版本控制.这实际上是我认为我将文件传输到构建服务器的方式.
6)对于大多数编译器,我们都坚持使用windows.

我现在相信要走的是外部构建服务器.过来还有一些障碍.我将假设我们必须通过版本控制软件将源文件传输到服务器.看到多个产品系列如何需要访问相同的编译器,为每个项目设置一个实例似乎并不实用.

为每个编译器创建一个存储库是否有意义,包括构建,源,包含,输出等文件夹…然后在用户端有脚本负责将文件从IDE的文件结构移动到所需的文件结构编译器的结构？这种方法可以防止项目存储库被破坏,并提供编译器使用次数的结果.感谢到目前为止所有的好回应！

解决方法 在我看来,实现自动构建服务器将是您尝试实现的最干净的解决方案.带来额外的好处……持续集成！ (我稍后会谈到CI).

有很多工具可供使用. @Clifford已经提到过CMake.但其他一些是：

> Hudson(开源)
> CruiseControl(开源)
> TeamCity(商业 – 但它有一个相当慷慨的免费版本,允许最多3个构建代理和20个构建配置.BrachCity的企业版是我公司使用的,所以我的答案将面向这个,因为它是我所知道但概念可能适用于多种工具)

首先,我将尝试解释我们的工作,并建议这可能对您有用.我并不认为这是可接受的做事方式,但它对我们有用.正如我所提到的,我们将TeamCity用于构建服务器.每个软件项目都添加到TeamCity中,并建立构建配置.构建配置告诉TeamCity何时构建,如何构建以及项目的SCM存储库所在的位置.我们为每个项目使用两种不同的构建配置,一种称为“集成”,它监视项目的SCM存储库,并在检测到签入时触发增量构建.我们称之为“夜间”的其他配置在每晚的设定时间触发并执行完全干净的构建.

IncIDentally just a quick note regarding SCM. For this to work cleanest I think the SCM for each project should be used in a stable trunk topology. If your developers all work from their own branches you’d probably need separate build configurations for each developer which I think would get unnecessarily messy. We’ve set up our build server with its own SCM user account but with read-only access.

因此,当为特定构建配置触发构建时,服务器从存储库中获取最新文件,并将它们发送到“构建代理”,该构建代理使用构建脚本执行构建.我们使用Rake来编写构建和自动化测试的脚本,但您可以使用任何东西.构建代理可以与服务器位于同一台PC上,但在我们的情况下,我们有一个单独的PC,因为我们的构建服务器位于ICT部门的中心位置,而我们需要我们的构建代理与我的团队实际位于一起(用于自动化 – 目标测试).因此,您使用的工具链将安装在构建代理上.

这怎么可能对你有用？

让我们说你为TIDyDog工作,你有两个项目：

>“PoopScoop”基于使用C18编译器编译的PIC18F目标,其主干位于您的SCM中// PoopScoop / TRUNK /
>“PoopBag”基于使用GCC编译的ColdFire目标,其主干位于// PoopBag / TRUNK /

构建所有项目所需的编译器安装在构建代理上(我们称之为TIDyDogBuilder).这是运行构建服务器的同一台PC还是单独的盒子取决于您的情况.每个项目都有自己的构建脚本(例如//PoopScoop/Rakefile.rb和//PoopBag/Rakefile.rb),它处理源文件依赖关系和调用适当的编译器.例如,您可以转到// PoopScoop /命令提示符,输入rake,构建脚本将负责在命令提示符下编译PoopScoop项目.

然后,您可以在构建服务器上设置构建配置.例如,PoopScoop的构建配置将指定您正在使用的SCM工具和存储库位置(例如// PoopScoop / TRUNK /),指定要使用的构建代理(例如TIDyDogBuilder),指定在何处查找相应的构建脚本和任何必要的命令(例如//PoopScoop/Rakefile.rb用rake incremental：build调用)并指定触发构建的事件(例如检测到// PoopScoop / TRUNK /的签到).因此,如果有人向//PoopScoop/TRUNK/Source/Scooper.c提交更改,构建服务器会检测到此更改,从存储库中获取源文件的最新修订版并将其发送到构建代理程序以进行编译使用构建脚本,最后通过电子邮件发送每个开发人员,这些开发人员使用构建结果更改构建.

如果您的项目需要针对多个目标进行编译,您只需修改项目的构建脚本来处理这个问题(例如,您可能有rake build之类的命令：PIC18或rake build：Coldfire)并在构建服务器上设置单独的构建配置每个目标.

持续集成

因此,使用此系统,您可以持续集成并运行.修改构建脚本以运行单元测试以及编译项目,并且可以在每次更改后自动执行单元测试.这样做的动机是尽可能早地解决问题,因为你在开发过程中而不是在验证活动中感到惊讶.

闭幕思考

>没有所有工具链安装的开发人员在某种程度上取决于他们最常做的工作.如果是我和我的工作往往是低级别的,与硬件交互很多,没有我的工作站上的编译器会惹恼我的bejeezes.另一方面,如果我主要在应用程序级别工作并且可能存在硬件依赖性,那么它可能不是一个问题.> TeamCity有一个Eclipse插件,功能非常酷.您可以执行个人构建,这意味着开发人员可以针对任何给定的构建配置运行待定更改列表的构建.这意味着开发人员在构建服务器上启动预先提交的代码的构建,而无需将其代码实际提交给SCM.我们使用它来对我们当前的单元测试和静态分析进行试验性更改,因为我们的昂贵测试工具仅安装在构建代理上.>关于在“在路上”访问构建工件时我同意,像你的内联网VPN这样的东西可能是最简单的选择.

总结

以上是内存溢出为你收集整理的如何在外部服务器上安装和使用嵌入式C的编译器？全部内容，希望文章能够帮你解决如何在外部服务器上安装和使用嵌入式C的编译器？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。