Windows CE 应用程序的自动构建
我正在尝试设置 Windows CE 应用程序的自动构建。然而， 我们正在与我们的应用程序同时发展我们的平台（添加 扩展卡、新服务等）。我希望能够关联我的 应用程序使用某个版本的 SDK 构建，并且具有多个版本 安装 SDK（不太可取的选项）或使用我的 SDK 版本化 应用程序（最优选的选项）。我希望能够运行并行构建 因此 SDK 应该位于我的项目本地，而不是在项目之间共享。
目前我能做的就是安装 SDK 并移动标头 和库到我的项目然后添加相对路径到我的项目包括 和库。我的问题是：除了标头和库之外还有更多东西 是随 SDK 一起安装的，所以如果我构建一个 具有较旧标头和库以及安装较新 SDK 的应用程序（或较新 标头和库比安装的 SDK 好）？
另一种方法是将 Visual Studio/命令行工具重定向到我自己的 header/libs 和 Properties.xml （但我还没想好如何做到这一点）。
以前有人这样做过吗？
谢谢，
亚历克西斯
I am trying to setup an automated build of my Windows CE application. However,
we are evolving our Platform at the same time as our application (adding
extension cards, new services, etc). I want to be able to associate my
application build with a version of the SDK and either have multiple versions of
the SDK installed (less preferable option) or have the SDK versionned with my
application (most preferable option). I want to be able to run parallel builds
so the SDK should be local to my project and not shared between projects.
Currently what I have been able to do is install the SDK and move the headers
and libraries to my project then add the relative path to my project includes
and libs. My question is: there are more things than the headers and libraries
that are installed with the SDK so could I run into trouble if I build an
application with older header and libs and a newer SDK installed (or newer
header and libs than the SDK installed)?
Another way would be to redirect Visual Studio/the command line tools to my own
header/libs and Properties.xml (but I haven't figured how to do that).
Has anybody done this before?
Thanks,
Alexis
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这实际上是一个相当广泛的问题，涵盖了几个领域。首先让我们看看 SDK 到底是什么以及它包含什么。
创建平台时，您将包含目录项。其中每个项目都有一组关联的头文件和 lib 文件。当您滚动 SDK 时，滚动会在每个处理器的基础上合并每个目录组件的所有标头和库（因为 SDK 可以支持多个处理器）。它还添加您在平台 BSP 中定义的任何“额外”文件（例如模拟器 BSP 将包含模拟器映像），并且还包括 SDK 定义中专门定义的任何额外文件。
那么SDK的内容什么时候会发生变化呢？每当您对平台中包含的目录项进行更改时，或者当您明确选择添加或删除 SDK 滚轮中定义的额外文件时。
对于自动化来说，这非常简单。我们倾向于做的（多年来与许多公司合作）是定义一组非常非常广泛的目录组件。基本上从目录中扔进厨房水槽。
不要添加任何自定义文件（因此，如果您有驱动程序或其他内容的自定义标头，请勿将它们包含在 SDK 中）。而是手动将这些文件发布到公共文件夹。将此公用文件夹添加到应用程序的“其他包含文件路径”中。
现在您可以随意修改平台而不影响应用程序。唯一的潜在问题是，您可能会使用由于许可证或大小限制而实际上最终从平台上删除的标头或库。
自动化所有这些实际上是一个完全独立的问题，而且您似乎实际上并不是在问如何进行构建自动化本身。
This is actually a pretty broad question covering a few area. First let's look at what an SDK actually is and what it contains.
When you create a platform, you include Catalog items. Each of those items has a set of associated header and lib files. When you roll an SDK, the roller coalesces all of those headers and libs for each catalog component, on a per-processor basis (since an SDK can support multiple processors). It also adds in any "extra" files that you define in your platform BSP (like the emulator BSP will include the emulator image) and it also includes any extra files specifically defined in the SDK definition.
So when does the contents of an SDK change? Well any time you make a change to the catalog items included in your platform, or when you explicitly choose to add or remove the extra files defined in the SDK roller.
For automation it's pretty simple. What we tend to do (and it's worked for years with many companies) is to define a very, very broad set of catlaog components. Basically throw in the kitchen sink from the catalog.
Do not add any custom files (so if you have custom headers for a driver or whatever, do not include them in the SDK). Instead publish these files manually to a common folder. Add this common folder to the applications "Additional Include Files Path".
Now you can modify the platform at will without affecting the app. The only potential problem is that you might use a header or lib that you actually end up cutting fromt he platform due to license or size restrictions.
Automating all of this is really a completely separate question, and it doesn't seem like you're actually asking how to do the build automation itself.
我建议您使用彻底的配置（版本）管理策略来处理它：只需排除混合头文件和库版本的可能性即可。即使它有效，它也肯定是一个不受支持的配置，这可能会给你带来一些奇怪的怪癖。
微软的工具让这一切变得不容易，因为他们喜欢 c:\program files 这样的位置......
但如果你能保证所有工具都处于版本控制之下，那么你随时可以回滚工具的某个版本。留意注册表关联。
如果您可以制作相同的二进制版本（即没有嵌入日期/版本号！），您可以验证在迁移到配置管理中的某个版本时是否可以在两台不同的计算机上重建相同的二进制文件。这将花费大量时间，但远不如您处于 SDK 版本冲突的不受控制环境中花费的时间那么多！
I suggest you deal with it by using a throrough configuration (version) management strategy: just rule out the chance that you mix up versions of header files and libraries. Even if it works, it is for sure an unsupported configration, which can get you some strange quircks.
Microsoft tools make it not easy, by their love for locations like c:\program files....
but if you can guarantee that all tools are under version control, you can always roll back a version of the tools. Watch out for registry associations.
If you can make identical binary builds (i.e. no dates/build numbers embedded!) you can verifiy that you can rebuild the same binary on 2 different machines when moving to a certain version in configuration management. It will cost a lot of time, but not nearly as much time as it will cost when you'd be in an uncontrolled environment with SDK version conflicts!
我们生成 SDK，然后将 libs/headers 复制到共享 svn 文件夹中。每次我们构建新的 SDK 时都会更新此文件夹。我们唯一需要 SDK 的就是将处理器平台安装到 Visual Studio 中。完成后，我们的应用程序使用 svn:externals 提取标头/库。
这样，我们的应用程序的旧版本仍然可以使用其原始 SDK 来启动和编译。否则，每当我们想要使用不同的分支时，我们都必须手动卸载/重新安装 SDK。
我曾经考虑过从 SDK 中提取所有文件，以便它只安装 VS 平台所需的注册表项，但我太懒了，放弃了。
We generate the SDK, but then copy the libs/headers into a shared svn folder. This folder is updated every time we build a new SDK. The only thing we need the SDK for is to install the processor platforms into Visual Studio. Once that is done, our application pulls in the headers/libs using svn:externals.
This way, old versions of our app can still be brought up and compiled with their original SDK. Otherwise, we would have to manually uninstall/reinstall the SDK whenever we wanted to work with a different branch.
I once looked into extracting all of the files from the SDK, so that it only installs the registry entries VS needs for the platform, but I got lazy and gave up.
听起来你想玩一下 PB 从中获取信息的 PATH 环境。我的意思是（据我了解），您希望 2 个构建将从 2 个不同位置获取文件，对吗？在这种情况下，您可以运行不同的批处理文件来设置适当的环境设置，然后每个批处理文件的构建将有所不同。
以下博客对 Platform Builder 的构建工具进行了精彩的评论（链接）。
您想要使用 INCLUDES 宏来控制 PB 从何处获取头文件，以便每次链接不同的库时，您必须使库的路径由您将在批处理文件中设置的宏组成，例如：
SOURCELIBS=
$(_MY_PREDEFINED_PATH_TO_THE_LIBS)\lib\libName.lib
然后在批处理文件中您将设置不同的 _MY_PREDEFINED_PATH_TO_THE_LIBS
Sounds like you want to play with the PATH environment that PB sucks its information from. I mean (from what I understand), you want that 2 builds will take files from 2 different locations, right? In that case you can run different batch files to setup the appropriate environment settings and then the build will be different for each batch file.
The following blog has an excellent review of the build tools Platform Builder has (link).
You want to play with the INCLUDES macro to control where PB takes the headers files from and in order to link against different libs each time you will have to make the paths of the libs be comprised of a macro that you will set in the batch file, for example:
SOURCELIBS=<br>
$(_MY_PREDEFINED_PATH_TO_THE_LIBS)\lib\libName.lib
Then in the batch file you will set a different _MY_PREDEFINED_PATH_TO_THE_LIBS