Delphi IDE 本身就是一个插件模式的工具，插件的好处不用多说。运行包的BPL，其实就是众多单元的集合，因此可以再次重新组合，只要你将各个BPL包用到的单元再组合一次！
本文以 http://code.google.com/p/tangram-plugin-framework/ 插件框架自带的BPL包合并向导工具做一次图文介绍！
1、安装好开源插件框架 tangram-plugin后，然后点击 菜单 File->New->Others，找到tangram FrameWork里的包合并向导，
2、Dev控件堪称独孤求败，最强也是最肥的数据库解决方案。我们以Dev套件包为准，合并Dev几十个BPL包为一个BPL包。
这里用到dev功能是cxGirid，treelist和垂直表格，如果用到其他的功能，涉及的BPL会有所不同！
选择单元
3、生成DPK工程，改名为Dev.BPL，记得保存。DPK文件如果没有生成，请先带一个空白工程，然后再用向导生成DPK，即重复上面的步骤。生成DPK后，再移除原来的DPR工程。
4、有可能碰到重复的单元，已经在别的包被引用了，我们的原则是，只封装Dev的单元。
（Dev的单元名好区分，都是以cx或dx打头。）比如sysInit，在 contains 按 CTRL+Y删除即可。
5、编译会提示，我们新的Dev包，引用到其他单元，在不同的BPL里。选择View details可以查看引用到详细单元。
按“OK”按钮，将引用到的其他包名（BPL），记录在 Dev.DPK里的require 区域。
6、输出BPL和DCP目录，最好是当前目录下，否则又要去delphi的DCP和BPL目录查找，太麻烦。这两个目录输入“点”字符：“.”，表示当前路径。
7、按Build 编译，生成Dev.BPL和Dev.DCP在当前路径下。新的Dev.BPL为 9M左右，比杨玉环还肥。
8、我们用ASPACK给BPL减肥一下，大概可以压缩到只有53%大小，只有4M多，减肥效果明显。
9、我们做一个简单的例子，将新的BPL和DCP放在EXE当前目录下。配置工程选项，选择Packages，在Build with runtime packages里输入
vcl;rtl;dev。这里必须要说一下 vcl;rtl 这两个包是delphi的核心运行包，尤其是基于DLL插件的框架，如果带包编译，必须少不了这2个包。引用vcl;rtl 这2个包，避免了很多DLL的麻烦和痛苦，如焦点切换，application共享等问题。
运行后，程序正确。新的EXE只有700K不到，经过ASPACK压缩后，只有200多K。
点评：BPL合并方式，简化了发布程序带来的痛苦，可以将系统的BPL和第三方的BPL各自合并。新的BPL并不影响原来的BPL或者第三方控件的开发环境，这只是运行包而已，在发布的时候带上即可。任何绿色插件程序文件，一般都会放在当前目录，尽量避免丢到syste32目录，这是微软windows的一个操作恶习，将系统目录当成垃圾桶。delphi的插件模式简单而透明，不会依赖系统，相反，.Net 4.0自带的发布版FrameWork，40多M，安装后目录上百兆，而且狂写系统注册表。.Net框架不会给你绿色试用，这已经违背了绿色软件的原则。注册表臃肿的后果，windows会越来越慢。
相信原生程序和托管程序之争会一直延续下去。.net似乎已经没有搞头，只有不停在语法上折腾，而折腾的后果，导致程序兼容性不够好（兼容性比JDK差多了）。如果你的操作系统自带了众多.Net 版本呢：1.0/1.1/2.0/3.0/3.5/4.0........XXX.0，每个.Net版本还有小版本号，诸如SP1，SP2，SP3等，请不要奇怪。未来的windows8/windows9/WIN X。。。。，Net框架加上加上几万种的驱动程序，windows上百G安装大小并不奇怪。.Net发布复杂性还在于捆绑在操作系统上，有些特殊功能必须在windows上配置，而且需要管理员的权限。
简单而简洁，这是一切应用程序的基本要求。微软，请不要将.net 演变成 COM/COM+，请给我们一个简单而简洁，高效又安全的操作系统环境！
