10

我需要在 Linux 上提供我的 Delphi 解决方案，并且我已经在 Wine 和 Lazarus 上对它们进行了测试。从长远来看，我应该考虑哪些技术因素（编程、部署、维护等），以避免陷入维护噩梦。我保持我的 Windows 组件使用非常标准，以避免可能在跨平台上开发的复杂性。我正在寻找一些超越主观的确凿事实。我不想考虑 .Net/Mono，因为这会让我立即退缩（上市延迟巨大），这是我无法承受的。

我能想到一些：

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

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

4

8 回答 8

18

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

我会开始用 lazarus 进行测试，并保留 Wine 作为备份，以防你绝望。

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

快速的时间线让我觉得 Apple 版本会使用 QT，而不是原生 api。

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

于 2009-05-21T07:49:20.693 回答
16

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

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

从经验来看，本地港口并不是在公园里散步：

  • Lazarus 可能不支持任何第三方组件。
  • 除非您也将 Windows 版本切换到 Lazarus，否则您将需要维护并行的 .lfm 文件，如果您确实切换，您将失去 Delphi IDE。与 Lazarus 一样好，它在抛光和功能方面远远落后于最新的 Delphis。
  • 如果您有一个完全独立的程序和不同的小部件集，则测试将需要更多的努力。在 Wine 上进行测试将更接近于在新的 Windows 版本上测试您现有的版本。
  • 在 FPC 具有等效功能之前，您将无法使用 Delphi 编译器引入的任何新功能（泛型、匿名方法）。
  • 大多数 64 位 Linux 安装不包括 32 位版本的 Gtk/Qt，安装它们可能很复杂且容易出错，因此您还需要编译 64 位版本的应用程序。
于 2009-05-21T12:44:51.143 回答
5

我通常会推荐使用 Lazarus。如果您依赖 WINE，您也会受到 WINE 错误的摆布，这可能会影响您的产品质量。在 Windows 环境中使用 Lazarus + FPC 甚至可能很有用。

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

于 2009-05-21T07:17:56.387 回答
4

查看 Codegear 的计划——在 DelphiLive 2009 上搜索一些路线图提示——在 Linux 和 Mac 上提供本机 Delphi，我现在会选择 Lazarus。您可以将自己从 Wine 管理中解放出来，以后可以将您的应用程序移植到本机。（正如有人所说：德尔福将像一个有企鹅、老虎、豹子和雪豹的大动物园。）

当然，移植将涉及退出一些工作。但是，如果您仔细查看 unicode 之类的问题并防止出现最常见的错误，那应该是相当容易的。

在delphifeeds上搜索unicode 和路线图以获取更多提示。

于 2009-05-21T07:41:55.887 回答
3

我认为 Wine 或 Lazarus 都可能适合您。我已经用 wine 测试了我们的一些相当大的 Delphi 应用程序（许多 3rd 方控件），它们运行得很好。有一些恼人的字体问题。真正失败的两件事主要是我使用 TWebBrowser 的地方（看起来它几乎可以工作，我认为它使用的是壁虎渲染引擎而不是 IE）。另一个是多层（Datasnap）服务器，它运行但我不知道如何连接。

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

如果你已经有一个可以工作的应用程序，那么试试 wine - 测试不会有坏处。

要考虑的另一件事是您的用户是谁（以及有多少）？如果他们是 Linux 极客，那么配置和调整 wine 将毫无问题（尽管他们可能会发现使用本机 Windows 应用程序令人反感）。如果是一群祖母，那就另当别论了。

于 2009-05-22T02:55:19.273 回答
2

Free Pascal Compiler/Lazarus 不接近最新的 Delphi 功能，但它相当稳定，即使仍有 bug 需要查找。

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

但它做了 Delphi/Kylix 曾经尝试过的事情。交叉构建！通过使用它，您可以从一个平台编译到另一个平台。

于 2009-06-05T12:32:36.687 回答
1

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

于 2009-09-03T14:35:36.460 回答
1

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

一旦解决了这个问题，就该看看你的 GUI 了。如果您使用大量封闭源代码的第 3 方商业组件，那么您可能无法轻松转换 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 列表。

Wine 是一个巨大的矫枉过正，除非你需要在明天几乎不做任何修改的情况下推出一个 Linux/OS X 应用程序。（在这种情况下，为什么不直接使用 VMWare？）

于 2013-09-03T01:51:12.723 回答