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

有很多工具可供使用. @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这样的东西可能是最简单的选择.