我正在尝试设置Windows CE应用程序的自动构建。然而, 我们正在与我们的应用程序同时发展我们的平台(添加 扩展卡,新服务等)。我希望能够关联我的 应用程序使用SDK的版本构建,并且具有多个版本的 SDK安装(不太喜欢的选项)或SDK版本与我的版本 申请(最可取的选择)。我希望能够运行并行构建 因此SDK应该是我的项目的本地,而不是项目之间共享。

目前我能够做的是安装SDK并移动标题 和我的项目库然后添加我的项目包括的相对路径 和libs。我的问题是:标题和库有更多的东西 随SDK一起安装,如果我构建一个,我会遇到麻烦 应用程序使用较旧的头文件和库以及安装的较新SDK(或更新版本 头文件和库比安装的SDK好吗?

另一种方法是将Visual Studio /命令行工具重定向到我自己的工具 header / libs和Properties.xml(但我还没想过如何做到这一点)。

以前是否有人这样做过?

谢谢,

亚历

有帮助吗?

解决方案

这实际上是涉及一些领域的相当广泛的问题。首先让我们看看SDK实际上是什么以及它包含的内容。

创建平台时,包括目录项。每个项目都有一组关联的头文件和lib文件。当您滚动SDK时,滚动器会在每个处理器的基础上为每个目录组件合并所有这些头文件和库(因为SDK可以支持多个处理器)。它还增加了任何“额外”的功能。您在平台BSP中定义的文件(如模拟器BSP将包含模拟器映像),它还包括SDK定义中专门定义的任何额外文件。

那么什么时候SDK的内容会发生变化?每当您对平台中包含的目录项进行更改时,或者您明确选择添加或删除SDK滚轴中定义的额外文件时。

对于自动化而言,它非常简单。我们倾向于做(并且它与许多公司合作多年)是定义一组非常非常广泛的catlaog组件。基本上从目录中扔进厨房水槽。

不要添加任何自定义文件(因此,如果您有驱动程序或其他任何内容的自定义标头,请不要在SDK中包含它们)。而是手动将这些文件发布到公共文件夹。将此公共文件夹添加到应用程序“Additional Include Files Path”。

现在您可以随意修改平台而不会影响应用程序。唯一可能存在的问题是,由于许可或大小限制,您可能会使用最终从平台上切割的标题或库。

自动化这一切实际上是一个完全独立的问题,而且您似乎并没有真正询问如何进行构建自动化。

其他提示

听起来你想玩PB吸收其信息的PATH环境。我的意思是(根据我的理解),你想要2个版本将从2个不同的位置获取文件,对吗?在这种情况下,您可以运行不同的批处理文件来设置适当的环境设置,然后每个批处理文件的构建将有所不同。 以下博客对Platform Builder具有的构建工具(链接)进行了精彩的评论。点击 您希望使用INCLUDES宏来控制PB从哪里获取头文件,以及每次必须使libs的路径由您将在批处理文件中设置的宏组成时链接到不同的libs ,例如:
SOURCELIBS = \结果 $(_ MY_PREDEFINED_PATH_TO_THE_LIBS)\ lib中\ libName.lib

然后在批处理文件中设置一个不同的_MY_PREDEFINED_PATH_TO_THE_LIBS

我建议您使用详细的配置(版本)管理策略来处理它:只是排除混合头文件和库版本的可能性。即使它有效,但肯定是一个不受支持的移民,这可能会让你有些奇怪的怪癖。

Microsoft工具让他们对c:\ program files等地点的热爱变得不容易。 但如果您可以保证所有工具都受版本控制,您可以随时回滚这些工具的版本。注意注册管理机构协会。

如果您可以制作相同的二进制版本(即没有嵌入日期/内部版本号!),您可以验证在配置管理中移动到某个版本时,您可以在两台不同的机器上重建相同的二进制文件。它会花费很多时间,但是当你处于一个不受控制的SDK版本冲突的环境中时,它的成本时间也不会太多!

我们生成SDK,但随后将libs / headers复制到共享的svn文件夹中。每次构建新SDK时都会更新此文件夹。我们唯一需要SDK的是将处理器平台安装到Visual Studio中。完成后,我们的应用程序使用svn:externals。

拉入headers / libs

这样,我们的应用程序的旧版本仍然可以使用其原始SDK进行调整和编译。否则,每当我们想要使用不同的分支时,我们就必须手动卸载/重新安装SDK。

我曾经考虑从SDK中提取所有文件,因此它只安装VS需要的注册表项,但是我懒得放弃。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top