【问题标题】:Nant: Building projects using svn-externalsNant:使用 svn-externals 构建项目
【发布时间】:2009-09-13 03:07:15
【问题描述】:

使用 subversion 和 Nant 进行构建。我有一个依赖于几个子项目的主项目。子项目作为单独的项目存在于 subversion 中。

我的问题是: 主项目中的 nant 构建脚本是否应该构建所有引用的子项目及其本身?还是子项目知道如何构建自己,我以某种方式从主构建文件中调用子项目构建文件,并以某种方式将所有输出组装到主项目构建输出中?

我目前有主项目构建文件构建所有子项目。也就是说,我对构建文件中的每个子项目都有 nant 目标。但是,这似乎在主构建文件和子项目之间建立了紧密的耦合。如果我能说“子项目知道如何构建自己”并要求他们从主项目构建自己并组装输出,那就太好了。

作为参考,我的存储库如下所示:

/Repo
  /MainProject
    /trunk
      /doc   <-- documentation
      /lib   <-- binary-only DLLs (usually 3rd party)
      /src   <-- source code for MainProject
      /svn-externals  <-- hold references to other projects in repository
...
  /ClassLib1
    /trunk
      /doc
      /lib
      /src
      /svn-externals
...
  /ClassLib2
    /trunk
      /doc
      /lib
      /src
      /svn-externals
...
  /ClassLibCommon
    /trunk
      /doc
      /lib
      /src
      /svn-externals

我正在使用 subversion svn-externals 属性引入子项目。所以我的工作副本是这样的:

/MainProject
  /build
  /doc
  /lib
  /src
    /MainProject
  /svn-externals
    /ClassLib1 <-- svn external to svn://xyz/repo/ClassLib1/trunk
      /doc
      /lib
      /src
      /svn-externals
        /ClassLibCommon <- svn external to svn://xyz/repo/ClassLibCommon/trunk
          ...
    /ClassLib2 <-- svn external to svn://xyz/repo/ClassLib2/trunk
      /doc
      /lib
      /src
      /svn-externals
        /ClassLibCommon <- svn external to svn://xyz/repo/ClassLibCommon/trunk
          ...

【问题讨论】:

    标签: svn build-process nant project-structure svn-externals


    【解决方案1】:

    您的问题的答案当然是“视情况而定”。

    您没有说的是您如何在解决方案中引用“子项目”,或者它们是否被其他解决方案(主项目)使用?它们是项目参考吗?如果是这样,请调用 MSBuild 来构建解决方案。这将基于这些依赖项构建所有子项目。我只能假设这是您的设置方式。

    就个人而言,如果我有一个看起来像您的设置,我不会使用项目引用,也不会为每个项目的所有代码提供外部。我会像对待第三方 DLL 一样对待这些子项目。

    如果您这样做,您将使用 DLL 引用。这将子项目与主项目分离。这就是我要走的路,特别是如果这些子项目被其他项目引用。

    是的,现在您必须做出一些其他决定……例如如何将这些决定存储在源代码管理中。您可以在您的 lib 文件夹中包含外部文件......或者您可以将 DLL 的副本放入您的 lib 文件夹中。这还取决于您希望如何控制版本控制。

    此外,您没有提及是否使用某种类型的 CI,例如 CC.Net。如果你这样做了,如果任何子项目被修改,你可以让它触发主项目的重建。

    【讨论】:

    • 库项目被其他“主要”项目使用。它们是项目参考。两件事:1.图书馆经常变化。 2. 我认为传统观念是不要为你有源代码的东西存储二进制文件。
    • 视情况而定。对我来说,不要在一个以上的解决方案中引用一个项目。我认为共享库不是主项目的一部分。因此,就像将我的 Crystal 报表 DLL 放入 svn 一样,我也将我的内部框架 DLL 也放在那里。此外,DLL 引用使您可以更好地控制您在每个项目中使用的该库的版本。当然,您可以执行上述操作,而不是将二进制文件放入 svn。将它们放在网络共享上。
    • “对我来说,不要在多个解决方案中引用一个项目会覆盖它”我不确定我是否理解这一点。澄清一下,当我使用“项目”一词时,我的意思是一般意义上的,而不是视觉工作室意义上的。所以在我看来,根据定义,一个类库“项目”(实际上是它自己的解决方案)旨在用于多个解决方案。
    • 是的,这确实是一种偏好。正如我所说,根据您的描述,我不会在应用程序解决方案中包含共享 VS 项目的通用代码。我们包含那些与 svn 中的 3rd 方库相同的二进制文件。因此,构建一个不会触发构建另一个。
    猜你喜欢
    • 2010-10-06
    • 1970-01-01
    • 2010-09-10
    • 2010-11-15
    • 1970-01-01
    • 1970-01-01
    • 2010-11-16
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多