在项目中共享Delphi源文件的最佳方式是什么？ [英] What is the best way to share Delphi source files among projects?

问题描述

在项目之间共享Delphi源文件的最佳方式是什么？

澄清：我们要使用单个源文件在多个Delphi项目中。我们一直在使用我们的SCM工具将相同的文件放入多个文件夹，但这不是一个超级优雅的体验，我们也考虑迁移到不支持这一点的工具。

由于我一直在调查这个问题，我已经考虑了一些不同的方法，但是我想知道你在做什么，以及如何找到你的方法。 p>

重要场景

• 代码时间
  
  
  
  
  • 添加新的共享依赖关系应该需要明确的声明，以便共享被管理。
  
  
  • 添加一个新的共享依赖项应该比较简单它不应该需要一个复杂的过程。
    
    
    
    
    • 一个列出所有项目导入文件（从外部）的文件将是很好的。
    
    
  
  


• 编译时
  
  
  
  
  • 所有项目都应始终使用一个当前版本（当前的源同步状态加上本地编辑）。
    
    
    
    
    • （在不同的位置维护不同的版本应该使用文件分支，这不是主题。）
    
    
  
  
  • 每个项目是否应该能够影响共享文件的编译与不同的编译器设置（包括标志）是有争议的。
    
    
    
    
    • 可持续地始终保持（即长期）源代码更容易。
    
    
    • 可以说是
    
    
  
  
/ li>

• 调试时间
  
  
  
  
  • 当进入例程或设置断点时，源的正确版本应自动打开。
  
  
  • 编辑显示的源将影响下一个构建。
    
    
    
    
    • 我们不想针对源的临时副本进行调试：我们可能会在混淆中丢失代码。
    
    
  
  

注意事项： / p>

• 近期：
  
  
  
  
  • 最简单的方法到位吗？
  
  


• 长期：
  
  
  
  
  • 将最简单的使用和维护？
  
  

反馈！

Mattias

---

---更新 - -

感谢您的反馈，通过答案，评论和投票！

已经开始将共享文件放入一个制作人项目，并将已编译的文件列表导入到每个消费者项目中。这些项目与MSBuild联系在一起。一旦事情被确定下来，我会编辑这个问题和图书馆计划的答案，分享我所学到的知识。

请继续关注！ （但不要压住你的呼吸，你会在几分钟内窒息：P）

解决方案

系统的文件共享功能

• Pro：如果SCM系统支持，可以快速设置。


• Pro / Con：每个消费者项目都可以独立影响编译时间。


• Con：在本地工作副本中没有官方位置。
  
  
  
  
  • 这可能会导致混淆。
  
  


• Con：Source更改不会反映在其他位置，直到签到并重新检索。
  
  
  
  
  • 为了正确验证其他项目，在签到之前，可能是屁股的皇家痛苦。
  
  
  / li>
  
• Con：并不是所有的SCM系统都支持共享文件。
  
  
  
  
  • Subversion最接近的功能是文件夹级别svn：externals。
  
  

（编辑：重写这个以避免混淆。当然，每个人都应该使用 Source Control！:-)）

What is the best way to share Delphi source files among projects?

Clarification: We want to use a single source file in multiple Delphi projects. We've been using our SCM tool to put the same file into multiple folders, but this is not a super-elegant experience and we are also considering migrating to a tool that doesn't support this.

As I’ve been investigating this question, I’ve considered a few different approaches, but I’d like to know what you’re doing and how you find your approach.

Important Scenarios:

• Code-time
  • Adding a new sharing dependency should require explicit declaration, so that sharing is managed.
  • Adding a new sharing dependency should still be relatively simple; it should not require a complicated process.
    • One file which lists all of the project’s "imported" files (from externally) would be nice.
• Compile-time
  • All projects should always build with the one current version (current as of the source sync state plus local edits).
    • (Maintaining different versions in different locations should use file branching, which is not the topic, here.)
  • Whether each project should be able to affect the shared file’s compilation with different compiler settings (including flags) is arguable.
    • It’s arguably easier to maintain (i.e. long-term) source code that is always built consistently.
    • It’s arguably easier to make maintenance fixes (i.e. short-term) if the scope of said changes can easily be restricted to one project.
• Debug-time
  • The correct version of the source should automatically open, when stepping into a routine or setting a breakpoint.
  • Editing the displayed source should affect the next build.
    • We do not want to debug against a temporary copy of the source: we'd probably lose code, in the confusion.

Considerations:

• Near-Term:
  • What approach will be simplest to put in place?
• Long-Term:
  • What approach will be simplest to use and maintain?

Thanks, in advance, for your feedback!

Mattias

---

--- UPDATE ---

Thanks for your feedback, via answers, comments, and votes!

I've started down the path of putting shared files into one "producer" project and importing a list of compiled files into each "consumer" project. The projects are being linked together with MSBuild. Once things are more nailed-down, I'll edit this question and the "Library Project" answer, to share what I've learned.

Stay tuned! (But don't hold your breath; you'll asphyxiate within minutes! :P )

解决方案

Use Source Control System's File Sharing Feature

• Pro: Fast and easy to set up, if the SCM system supports it.
• Pro/Con: Each consumer project can independently affect compile-time.
• Con: There is no official location, in the local working copy of sources.
  • This can lead to confusion.
• Con: Source changes are not reflected in other locations until checkin and re-retrieve.
  • To properly verify other projects, before checkin, is possible but a royal pain in the butt.
• Con: Not all SCM systems support shared files.
  • Subversion’s closest feature is folder-level svn:externals.

(Edit: Retitled this to avoid confusion. Of course, everyone should use Source Control! :-) )

这篇关于在项目中共享Delphi源文件的最佳方式是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！