什么是我在Linux上的Delphi应用程序的最佳解决方案 - Delphi + Wine或Lazarus？

Question

我需要在Linux上提供我的Delphi解决方案，并且我已经在Wine和Lazarus上测试了它们。从长远来看，我应该考虑哪些技术因素（编程，部署，维护等），以避免在维护噩梦中降落。我保持我的Windows组件使用非常标准，以避免可能在跨平台上开发的复杂性。我正在寻找一些不仅仅是主观的事实。我不想考虑.Net / Mono，因为这会让我立即回归（巨大的延迟推向市场），这是我买不起的。

我能想到一些：

1. Lazaraus可能需要一些（更改）编程才能使代码正常工作。
2. 葡萄酒是一个难以维持在大量客户群中的环境。

您对此的贡献将不胜感激。

Answer 1

我想说那里没有黄金法则。这实际上取决于Lazarus支持您使用的组件数量。

我开始用拉撒路测试并保留葡萄酒作为备用，以防你绝望。

Codegear计划仍然非常模糊（他们只是“看着它”，但同时他们在两个完整版本上涂抹了64位推出，所以即使这取得了进展，这可能还需要一段时间）

快速时间表让我觉得Apple版本将使用QT，而不是原生apis。

更新：近4年，仍然没有Linux支持。树木生长得更快。

Answer 2

我必须不同意这里的其他人，并建议您使用Wine。 Google正在通过Wine安装Picassa，您可以做同样的事情。他们没有依赖发行版安装的版本，而是在程序目录中预先配置了一个副本，并且具有可以测试的已知版本。

基本上你只需要询问Wine包装器不会提供什么样的本机端口。对于大多数Delphi应用程序，答案可能是主题，而其他很少。我们创建了一个本地端口，因此我们可以在较低级别访问文件系统，但在此之前，我们的产品几乎完美地用于Wine。

根据经验，本地港口不是在公园散步：

• Lazarus可能不支持任何第三方组件。
• 除非你将Windows版本切换到Lazarus，否则你需要维护parallal .lfm文件，如果你切换，你就会失去Delphi IDE。和拉撒路一样好，它远远落后于最新的Delphis的抛光和功能。
• 如果您有一个完全独立的程序和不同的小部件集，测试将需要更多的努力。对Wine的测试更接近于在新的Windows版本上测试现有版本。
• 在FPC具有相同的功能之前，您将无法使用Delphi编译器引入的任何新功能（泛型，匿名方法）。
• 大多数64位Linux安装程序不包含32位版本的Gtk / Qt，安装它们可能很复杂且容易出错，因此您还需要编译64位版本的应用程序。

Answer 3

我一般建议使用Lazarus。如果您依赖WINE，您也会受到WINE错误的影响，这可能会影响您的产品质量。在Windows环境中使用Lazarus + FPC甚至可能很有用。

另一种方法是使用虚拟化，但这取决于您正在编写的应用程序类型。

Answer 4

查看Codegear的计划 - 在DelphiLive 2009中搜索一些路线图提示 - 在Linux和Mac上提供原生Delphi，我现在想用Lazarus。您可以省去Wine管理员，之后可以将您的应用程序移植到本机。 （正如有人所说的那样：德尔福将像大型动物园一样拥有企鹅，老虎，豹子和雪豹。）

当然，移植会包含一些工作。但是如果你仔细研究像unicode这样的问题并防止做出最常见的错误，那就应该很容易了。

在delphifeeds上搜索unicode和路线图以获取进一步的提示。

Answer 5

我认为Wine或Lazarus可能适合你。我用葡萄酒测试了一些相当大的Delphi应用程序（许多第三方控件），并且它们运行得非常好。有一些烦人的字体问题。真正失败的两件事主要是我使用了TWebBrowser（看起来它几乎可以工作，我认为它使用的是gecko渲染引擎而不是IE）。另一个是muli-tier（Datasnap）服务器，运行但是，我无法确定如何连接。

我认为坚持Mac / Linux对Delphi的支持将是一个错误，他们可以为OS / X编译控制台“hello world”应用程序的事实令人印象深刻 - 但我认为移植VCL是一个不同的故事（除非你已经编写了一个控制台应用程序。）

如果你已经有了一份正常工作的应用程序，那就去试试吧 - 测试不会受到影响。

要考虑的另一件事是你的用户是谁（以及有多少人）？如果他们是Linux极客，那么他们将配置和调整葡萄酒没有问题（尽管他们可能会觉得使用本机Windows应用程序是冒犯性的）。如果这是一群祖母，那么这是一个不同的故事。

Answer 6

免费的Pascal编译器/ Lazarus并不接近最新的Delphi功能，但它仍然非常稳定，即使仍然存在缺陷。

此外，生成的可执行文件似乎更大，但它肯定比使用VM或使用Wine本身部署更小。

但这确实是Delphi / Kylix尝试过的。 Cross build！通过使用它，您可以从平台编译到另一个平台。

Answer 7

实际上我们将Wine用于我们的ShareTeam产品......我们在Lazarus上有一个测试版本，这是一个很好的工具并且有很多优点，但目前还不完整。   我认为目前最好使用wine如果工作不简单，将Delphi应用程序转换为Lazarus / FreePascal并不简单。   我个人希望Embarcadero能够制作一个跨平台版本的Delphi，而不像Prism那样与Delphi有很大不同。

Answer 8

首先，您应该尝试确保您的GUI代码和非GUI后端代码完全分离到GUI应用程序和库中（如果它们尚未完成）。这样可以更容易地进行测试，也可以更轻松地实现命令行界面，Web界面等。在大多数情况下，这些库（带有对象和过程的单元文件）应该可以在FreePascal上轻松编译，但是您应该检查并调试非GUI代码第一

一旦完成，就该看看你的GUI了。如果您使用大量的闭源第三方商业组件，那么您可能很难轻松转换GUI。如果您主要使用库存组件和/或已移植到Lazarus的组件，那么您可能确实能够转换GUI并按原样使用它。

请注意，由于Mac OS和Linux程序通常假设看起来不同，您可能需要考虑这一点，具体取决于您的应用程序。可能的方法包括： 1.即使在Windows上也使用Lazarus，并对所有平台使用相同的GUI代码。 2.仅在OS X和Linux上使用Lazarus，并在转换后自定义GUI。 3.为OS X编写本机GUI（使用Cocoa和XCode），然后链接到Pascal代码以进行非GUI处理。在Linux上这种事情不太必要，但是您可以选择使用LCL（VCL）后端制作工具包。

每种方法都有强有力的支持者，但哪一种是正确的取决于你的“情况”和你的目标。

如果您的主要兴趣是OS X，请考虑加入MacPascal列表。

除非你明天需要一个Linux / OS X应用程序，几乎不需要修改，否则Wine是一个巨大的过度杀伤力。 （在这种情况下，为什么不使用VMWare？）