我需要让我的Delphi解决方案在Linux上可用，我已经在Wine和Lazarus上进行了测试。从长远来看，我应该考虑哪些技术因素（编程、部署、维护等），以避免陷入维护的恶梦。我把我的Windows组件用得很标准，以避免在跨平台上可能出现的复杂情况。我正在寻找一些铁的事实，这些事实应该超越主观。我不想考虑.Net/Mono，因为这将使我立即陷入困境（巨大的市场延迟），我无法承受。
我可以想到一些。
如果您能在这方面做出贡献，我们将不胜感激。
|
|
对于我在Linux上的Delphi应用程序，什么是最好的解决方案 - Delphi+Wine或Lazarus？
10
人关注
Johan Bresler
发布于
2009-05-21
8
个回答
Marco van de Voort
发布于
2009-09-03
已采纳
0
人赞同
我想说的是，这并没有什么黄金法则。这真的取决于您使用的组件在多大程度上被Lazarus支持。
我会开始用lazarus进行测试，并保留Wine作为备份，以备你走投无路。
Codegear的计划仍然非常模糊（他们只是 "在看"，但同时他们把64位的推广涂抹在两个完整的版本上，所以即使这取得了进展，这也需要相当长的时间）。
快速的时间表使我认为苹果版本将使用QT，而不是本地apis。
更新。 近4年了，仍然没有Linux支持。树木生长得更快。
mghie
：
谢谢你在目前相信（其中一个）下一个Delphi版本将允许简单地按下一个按钮并获得所有这些美妙的Linux和Mac OS X应用程序的星空中发出了理性的声音。
好吧，我不想太消极，他们至少有Kylix代码库，以及作为64位努力的一部分的修订版（并希望是可移植的）编译器。 FPC/Lazarus也通过同样的途径实现了多平台和后来的体系结构。 然而，实际上没有足够的内容可供评论。
mghie。原来是在重新架构到一个不同的GUI库后按下按钮 :-)
Zoë Peterson
发布于
2009-09-03
0
人赞同
我不得不与这里的其他人意见相左，建议你使用Wine。 谷歌正在将Picassa与Wine安装在一起，你也可以做同样的事情。 与其依赖发行版安装的版本，他们在程序目录中有一个副本，已经预先配置好，并且有一个已知的版本，你可以进行测试。
基本上，你只需要问，本地端口能提供什么，而Wine包装器却不能。 对于大多数Delphi应用程序来说，答案可能是主题化，其他的就很少了。 我们做了一个本地端口，这样我们就可以在较低层次上访问文件系统，但在此之前，我们的产品在Wine上几乎完美地运行了多年。
从经验上讲，本地港口并不是在公园里散步。
谢谢你的发言--你确实增加了思考的内容。
我不同意第三方组件的说法。很多核心组件是被支持的，比如socket suites、ZeOS、VST、Comport、TeeChart等等，不胜枚举。 第二点我同意，至少是第一部分，如果你有大量的GUI，双重维护是很痛苦的。(我把我的大部分Lazarus项目都换成了在Windows上使用Lazarus，反正我也是因为win64才换的）FPC在D2009之前就发布了泛型。但不幸的是，CG实现了它们的不兼容。最后一点取决于你要走多远。Linux/PPC Sparc, ARM, Wince?首先看看64位Linux在这一点上是否有意义。
它支持多少个TMS和DevExpress组件？ 我肯定还漏掉了Ribbon控件、成像库、ZipForge/ziptv、VirtualShellTree、皮肤/主题、QuickReports等等。 也许维基已经过时了......
Mick
：
我同意Craig的观点。我关心的Delphi的控件在Lazarus上是没有的。DevExpress是一个
hugely
对Delphi（对我来说）重要的附加组件，在Lazarus上是没有的。这对我来说是个阻碍。
无论你喜欢与否，使用Wine以外的任何东西都意味着错过了大量的组件和明显更多的测试。 这同样适用于Lazarus、Kylix、Prism和Delphi 201x的跨平台工作。 我不认为使用Lazarus的Linux移植会比销售现有Delphi应用程序的大多数小型开发者的Wine有更好的投资回报。 我认为OS X的移植必须是原生的才能卖得好，而且我认为如果你必须要有一个原生的移植，FPC/Lazarus是最好的选择。 如果你不同意，就不要再对我说三道四，证明我错了。
sybreon
发布于
2009-09-03
0
人赞同
我一般会推荐使用Lazarus。如果您依赖WINE，您也会受到WINE错误的摆布，这可能会影响您的产品质量。在Windows环境下使用Lazarus+FPC甚至可能是有用的。
另一个选择是使用虚拟化，但这取决于你所编写的应用程序的类型。
Ralph M. Rickenbach
发布于
2009-09-03
0
人赞同
看着Codegear的计划--在DelphiLive 2009上搜索一些路线图的提示--在Linux和Mac上提供本地Delphi，我现在会选择Lazarus。你可以免去Wine的管理，以后可以把你的应用移植到本地。(正如有人所说。Delphi会像一个大动物园，里面有企鹅、老虎、豹子和雪豹。）
当然，移植会涉及一些工作。但是，如果你仔细研究了诸如unicode等问题，并防止犯最常见的错误，应该是相当容易的。
搜索 delphifeeds 统一代码和路线图的进一步提示。
Alister
发布于
2009-09-03
0
人赞同
我认为Wine或Lazarus可能对你有用。 我已经用wine测试了我们一些相当大的Delphi应用程序（许多第三方控件），它们运行得很好。 有几个恼人的字体问题。 有两件真正失败的事情是我使用了TWebBrowser（它看起来几乎可以工作，我想它使用了gecko渲染引擎而不是IE）。 另一个是一个多层（Datasnap）服务器，它运行了，但我无法解决如何连接的问题。
我认为坚持对Delphi的Mac/Linux支持是一个错误，他们能够为OS/X编译一个控制台 "hello world "应用程序的事实令人印象深刻 - 但我认为移植VCL是一个不同的故事（除非你已经写了一个控制台应用程序）。
如果你已经有一个正在运行的应用程序，那么给葡萄酒一个机会--测试是没有坏处的。
另一件要考虑的事情是你的用户是谁（以及有多少人）？ 如果他们是Linux极客，那么他们在配置和调整wine方面不会有任何问题（尽管他们可能会觉得使用原生的windows应用程序令人反感）。 如果是一群老奶奶，那就是另外一回事了。
mghie
：
他们能够为Mac OS X编译 "hello world "这一事实并不令人印象深刻，这只是最基本的。我的意思是，我们谈论的是一家已经建立了20多年的X86开发工具的公司！（我想他们不会以PPC为目标，这样做没有什么意义）。(我想他们不会以PPC为目标，这样做已经没有什么意义了。) 否则，你的答案是好的，+1。
(OS X ABI有点古怪，有对齐字节，寄存器中的小记录，每个函数中的堆栈对齐等等。所以这并不完全是小事一桩)
mghie
：
@Marco：这可能不是小事，但有大量的现有技术可以看。经过这么长时间，他们应该知道自己的东西。不管怎么说，现在要说服人们为一个开发工具买单，需要的不仅仅是解决一个 "不完全微不足道 "的问题。
哦，这不是问题所在。对于一个能够维护商业C++编译器的公司来说，这应该是一件轻而易举的事。
Caglar Toklu
发布于
2009-09-03
0
人赞同
Free Pascal Compiler/Lazarus并不接近Delphi的最新功能，但它相当稳定，尽管仍有一些Bug有待发现。
此外，产生的可执行文件似乎更大，但绝对比使用虚拟机或用Wine本身部署要小。
但它做了Delphi/Kylix曾经尝试过的事情。 Cross build !通过使用它，你可以从一个平台编译到另一个平台。
Noah
发布于
2009-09-03
0
人赞同
首先，你应该尽量确保你的GUI代码和非GUI的后端代码被干净地分离到GUI应用和库中，如果它们还没有分离的话。 这使得测试更容易，也更容易实现命令行界面、网络界面等。 这些库（包含对象和程序的单元文件）在大多数情况下应该很容易在FreePascal上编译，然而你应该先检查和调试非GUI代码。
一旦这个问题解决了，是时候看看你的GUI了。 如果您使用的是大量封闭的第三方商业组件，那么您可能就不太容易转换GUI了。 如果您使用的主要是库存组件和/或已经被移植到Lazarus的组件，那么您可能确实能够转换GUI并按原样使用它。
请注意，由于Mac OS和Linux程序通常是 supposed 来看起来不同，你可能要考虑，这取决于你的应用。 可能的方法包括。 1.即使在Windows上也使用Lazarus，并在所有平台上使用相同的GUI代码。 2.2.只在OS X和Linux上使用Lazarus，并在转换后将GUI定制为某种程度的本地外观。 3.3. 为OS X编码一个本地GUI（使用Cocoa和可能的XCode），然后链接到你的Pascal代码来处理非GUI。 这种事情在Linux上不太需要，但在那里你可以选择制作LCL（VCL）后端的工具箱。
每种方法都有强有力的支持者，但哪种方法是正确的，取决于你的 "情况 "和你的目标。
如果你的主要兴趣是OS X，考虑加入MacPascal列表。