Lazarus 实在太强了，可交叉编译以下CPU的程序： arm、i386、m68k、powerpc、sparc、x86_64，
可编译以下操作系统的程序：Linux、NetBSD、OpenBSD、Solaris、Win32、Win64、WinCE、go32v2、os2、beos、haiku、qnx、netware、wdosx、emx、watcom、netwlibc、amiga、atari、palmos、gba、nds、macos、morphos、embedded、symbian。
（http://wiki.freepascal.org/Main_Page/zh_CN ）
可作跨平台开发，只是用惯了 MMX 和 CnWizards, 一下子没有这两个套件很不习惯。Delphi 走到尽头了，希望 Lazarus 能继续燃烧 Pascal 的火种。

Delphi 走到尽头了？这可不是谁说了算的。

lazarus只是一个玩具，跟本不能真正用来开发
跨平台编译delphi也很快会有了，David I上次表示Delphi从来没有将业余的Lazarus放在眼里

另外，对于语言的局限是不对的，如果一门语言不符合生产需要
那么它再好也会被淘汰，哪怕是一门很好的语言
对于Delphi来说，国内是不景气，但是国外还是有相当多的公司在用
而且据我所知的，Delphi程序员的工资甚至超过VC程序员的
而很多国外牛人对于lazarus的看法，也是华丽有余，但实用不足的一个东西

跨平台编译器并不能把Win32下的代码编译去Linux
要编译Linux的程序，那个程序代码也必须用Linux的API和库
这和你维护两套代码有什么区别。。。。

[ 本帖最后由 rarnu 于 2009-5-9 06:43 编辑 ]

虽然目前应用人群还不广，但laz应该还是有比较强的生命力的，。期待它发展成熟后，再做支持不迟。

的確感覺像玩具，現在的人要求高，不單表現在所謂的強大功能，還有有良好的開發環境，完整的類庫，不然彙編可以做任何事情，為何沒有做任何事情？
其實對跨平臺的感覺是，應該不是想像中那麼好，假設你的開發工具能稱霸一方，不跨平臺也夠你滋潤的了。
我感覺很多開源的問題在於使用的方便性，商業的軟體，再怎麼說，人家都會考慮易用性，因為失去這個將失去用戶。試問有多少人是專家？另外一個角度來看，即使是專家，難道就喜歡複雜而不喜歡簡單？
不過到不是說lazarus沒用，只是相比商業軟體，真是有不少距離。對於多數人來說，穩定可靠的才是最重要的，如果基礎都丟棄，不可能成功的。

曾经看到有人提议CnWizards的开发组考虑一下对Lazarus的支持，结果论坛老大们说现在不打算支持，一个是它没有提供Open Tools API，二是它的用户太少，像橙子的意见就比较典型：

------------------------------------------------------------------
不知gold8有没有了解过lazarus的插件模式
那可是要重新编译IDE的活，lazarus的架构与delphi不同
它是完全没有所谓的“OTA”的
已经超过了二次开发的范围了。。。
一个IDE，若是只开放了控件的接口，那么必然只能够开发控件
lazarus现在就是这种情况

关于工作量的问题，也许没有必要讨论了
如果lazarus啥时把IDE的接口全部开放出来，或许cw还有可能写得上去
但是现在连个可用的接口都没有，巧妇难为无米之炊啊
我们也完全不可能自己直接去改lazarus的源码的
-----------------------------------------------------------------

于是橙子得出一个结论：Lazarus没有OTA，所以不能支持IDE扩展。事实证明，老大们也有看走眼的时候，Lazarus不仅有自己的OTA，而且有的地方做的比Delphi更好！也许是Lazarus比Delphi年纪小，它充分吸取Delphi的成功之处，还加以改进，以更加清晰的对象层次来构筑自己的OTA，Lazarus中的包CodeTools和IDEInft就是用于支持IDE扩展的基础，阅读SrcEditorIntf、CodeToolManager、CodeTree、CodeCache、CodeAtom、CustomCodeTool、IdeCommands等单元，我们可以发现类的组织和层次关联非常清晰，支持的方法更加人性化，虽然没有OTA那么博大精深，但也还算是组织得相当好了。

试看这样一个例子：
用户在代码编辑器中输入一个文字串（过程或者函数中的关键字），然后按快捷键，助手检测当前位置之前是否有分号，如果有，则取分号之后到当前位置间的所有字符为查询关键字，否则取当前位置向前的第一空格到当前位置间的所有字符为查询关键字，弹出查询窗口，在数据库中查询该关键字或关键字组合，每一个结果都有函数名、单元名、函数解释等内容，找到合适的过程或者函数，点击引用按钮，助手用被引用的函数代替刚才在代码编辑器中输入的那串文字，判断Uses节是否已经包含单元名，如未包含，则添加单元名。

效果如下图所示：（在新窗口中查看动画）


代码用Delphi编写完成后，尝试转换到Lazarus下，一番摸索之后，对Lazarus顿生好感，比如下面这句代码：
if not CodeTool.FindUnitInAllUsesSections(UpperCase(CodeHelperDlg.UsesUnitEdit.Text), NamePos, InPos) then
    CodeTool.AddUnitToMainUsesSection(CodeHelperDlg.UsesUnitEdit.Text, '', CodeToolBoss.SourceChangeCache);
判断单元是否已经包含在Uses节中，如果没有，则在接口部分的Uses节中添加该单元，如果添加该单元后代码行超过了行长80列的限制，还会自动换行。代码之简洁让人为之一振，在Delphi中实现同样的功能，我可是写了好几十行呢。类似于FindUnitInAllUsesSections、AddUnitToMainUsesSection这样的高度抽象、体贴开发者的过程和函数在Lazarus中随处可见，试问这样的支持环境和开发接口，我们还有理由视而不见吗？

不可否认，Lazarus还有很多不足，但是，事物都是发展变化的，Lazarus已经吸引了越来越多的关注，相信在众多开发者的参与下，必将快速走向成熟。。。

[ 本帖最后由 xychen 于 2009-5-9 17:40 编辑 ]

看走眼...有那么夸张吗，也许当时就是没有OTA这样类似的东西，现在不支持也不代表永远不支持，计划也不是一成不变的

下了个最新的版本看了下，的确是有所谓的“OTA”
但是在此基础上扩展与安装控件一样，依然需要重新编译IDE，风险实在太大了
这并不是一种良好的Extension解决方案，甚至可以说这种方案是极差的
举例来说，IE上也有很多插件，但是你需要装插件时就重新编译IE吗？这显然不可能

说几句吧，首先，配置路径很麻烦，特别是在跨平台编译方面
我曾尝试编译WinCE下的程序，照着wiki的内容整了大半天，就凭这点，足以让很多初学者望而却步
其次，Bug还是很多，比如说新建一个dll，里面加入uses Forms, Windows，再加一些杂七杂八的单元
然后你编译吧，一会好一会不好，稳定性还是欠佳

我一直都是说那么一句话，作为一种开发环境，作为一种语言，是让用户来“用”的
而开发厂商（或许跟本不能称之为厂商）没有权利让用户为其找bug，用户也没有这个义务
对于lazarus稍微宽容一点，毕竟它是免费的，但是请不要被这个免费的光环蒙蔽了双眼
我们作为用户来说，只有当一个东西在接受了事实的考验后，才是真正有价值的
但是现在全球范围内还不曾有过一个用lazarus开发的实用软件

另外再说一句，我以前也提到过，lazarus的开发者是一群学生在做毕业设计时搞出来的，他们用它来进行答辨
但是你怎么知道他们答辨过后，还会不会发展它呢？如果一个产品的背后，没有一个有实力的厂商支持
光靠那些学生，我个人的感觉是靠不住。现在毕竟不是20年前，几个人在家捣鼓一阵就能有不错的产品
用户的眼光和要求越来越苛刻，产品也必须时时向用户的实际需求靠拢

to 橙子：
你说Lazarus的起源是学生的毕业设计，这个我看到你多次提起，所以你怀疑他可能难以继续发展下去，如果是商业开发，你的理由是充分的，也是谨慎的。
我注意到一点，在说到Lazarus起源的时候，都说是1999年2月，Cliff Baeseman 、Shane Miller、Michael A. Hess等人因为原有的Megido计划（基于FPC的开源、跨平台Delphi克隆）搁置，于是启动Lazarus计划（圣经里面的Lazarus拯救过基督，所以取名Lazarus，因为他的出现拯救了Megido计划），没有说这是毕业设计啊。在Lazarus项目开始后，Marc Weustink和Mattias Gaertner分别与1999年8月和2000年9月加入， 他们一起努力，Lazarus开始慢慢发展起来。所以Lazarus的年纪也不差不多10岁了，哪里去找能跨越那么长时间的毕业设计啊？毕业答辩以后就不再搞了的担忧大可不必，而且我觉得所谓Lazarus起源于毕业设计一说也许本身就是以讹传讹。
Lazarus用于产品开发也许为时过早，但是，谁知道他后来会发展成啥样子呢？说不定成为GCC第二，成为跨平台开发的生力军呢。

[ 本帖最后由 xychen 于 2009-5-9 21:55 编辑 ]

话说他们的导师老板积极学习中国高校国情，像博士们没被剥削充分时被启用延期毕业的手段似的，一延期就是十年，这十年里年年都在做毕业设计年年都在答辩……

刘老大真幽默！关于Lazarus起源大家未必关心，人们更关注的是它的发展趋势。我们可以在网上看到Lazarus的开发组是有比较长远规划的，而且，打开About窗口中的贡献者名单，可以看到长长的一排，Lazarus不是某几个人的项目，它是很多开发人员的智慧结晶。一个开源工具的语言包就高达20种，起码说明有很多国家的开发者在关注着Lazarus。。。

[ 本帖最后由 xychen 于 2009-5-10 10:18 编辑 ]

最老早听说它是一个毕业设计项目，是Borland的人说的，因此我很少去关注它
即然现在正史被挖出来，它是一个广受关注的项目的话，我就得重视审视一下它了

就从我昨天晚上在它们的wiki上混了一夜的所看到的，简单的谈一下它所谓的“规划”
首先，完全没有看到有关编译器优化的计划，一个只包含空窗口的EXE 10M，这种体积是没有人可以接受的
而且用十六进制编辑器打开，可以看到许许多多废字节，跟本用不到的也在里面了
那个导入导出表实在太庞大，就凭这点，我想lazarus并没有一个优秀的编译器开发人员
其次，还是那个需要重新编译IDE的扩展方式，实在太烂了，这是w3c国际公约所不推荐的扩展方法
谁见过需要重新编译主程序的插件？除了lazarus外，绝无仅有
然后是跨平台编译器，说的很好听，支持了一大堆的东西，但是我除了Win32, WinCE, Ubuntu, Red Hat外，其他平台的编译都不曾通过
从win32下编译一个程序去Symbian?是个好主意，但是编译出来的程序17M（同样只有一个空窗口），而且在我的N98下跟本不能运行
FreeBSD也曾经被一位网友测试，lazarus的按FreeBSD编译的程序无法在上面运行。
个人感觉，这个东西吹的成份比实在的成份还要多，号称支持很多东西，但是真正支持的没几个

等明年Delphi自己的原生跨平台编译器面世后，lazarus该如何存活呢？

同时，在他们的规划里，我也没有看到他们对于bug的修正计划，甚至没有找到他们的“QC”
或许是我找得不够仔细，但是CodeGear的QC可是一眼就能看到的，这至少是一种面对用户的公开态度
如果QC都难以找到，那用户该如何汇报问题？如何帮助开发组修正bug？

我跟Michael联系过，他自己表示，现在活跃在lazarus的开发人员，只有18个人，许多人都是对它提出了意见或建议
或者是修改过控件，捐献过一定的代码，这些人都被列在了About的名单中。
Michael自己也说了，他现在在Turbo上班，也是业余的时间来搞lazarus，开发组里的其他成员大多也是这个情况
因此开发时间比较难以保证，并且至今为止，还没有一个厂商愿意为lazarus投资
所以说，lazarus要用在正式的企业项目中，现在还为时过早

[ 本帖最后由 rarnu 于 2009-5-10 12:04 编辑 ]

“我想lazarus并没有一个优秀的编辑器开发人员”
——大概是编译器？

没投资的话，开源免费的东西是很难做大的，毕竟参与人员都需要自己谋生，CnPack也有这个局限，脱不了俗。
现在就看谁能给Laz投钱了。

错别字已改。。。

牛啸很快就会有公司投资了。。。。

Lazarus重心在于提供良好的Framework和IDE，编译器的事情则是由FPC编译器组在不断优化。至于Lazarus生成的执行文件大的问题，我也很关注，希望开发组能早日改善这个缺点。
对于FPC本身，下面这个评测很有趣，可以了解一下FPC的性能：
http://www.cnblogs.com/gfkz/archive/2009/02/15/1390820.html

[ 本帖最后由 xychen 于 2009-5-10 13:47 编辑 ]

前辈看东西不仔细：


编译 WinCE 只需要改三个编译选项：
路径页的：[LCL窗口部件类型] 改为 Wince(beta)
代码页的[目瞟 OS] 改为Wince；[目标 CPU族] 改为 ARM


这个只需要将 [当出现运行错误时显示行号] 前的勾勾去掉就马上减肥了。
如果用 MCK 组件，还会骨瘦如柴呢.

同一套代码的Holle world,没用 KOL 大小约是 1.7M, 用了 KOL 的大约 60K,下面是同一套代码编译出来的两个Holle world程序：

Project.for.CE.exe 66.5K
Project.for.win.exe 64.3K

东兰梦舞用 Laz 做的 For CE 实际项目：