过一遍一个可执行文件(ELF)是怎么被操作系统(linux kernel)加载并执行的,就很清楚了.

http://heguangyu5.github.io/my-linux/html/20-init_post.html

@Sligcm

当然是改成动态下载编译好的.so,然后调用 `dl()` 加载进来.不过需要进一步完善一下当前的 dl()实现.
这个方法只能安装插件,不能卸载.

@aogg laravel 东西太多了,我在编译 Illuminate/Database 的过程中领教了一下,我自己就不搞了,有需要的人自己编译吧.

@happy32199 webman 自身已经成功编译了,但依赖注入不支持. 详见: https://www.workerman.net/a/1576 **4. 关于 webman 代码调整的说明**部分.

基于 webman 的项目要想成功编译还要等一等,如果 webman-admin 也成功编译了,那离实用就不远了.
当然这也看项目情况,如果没用到 trait 特性,那现在就可以编译了.
我看 webman-admin 的一堆依赖用到了 trait,如果 BPC 不支持 trait,就需要改动很多代码,所以下一步就把 trait 的实现提上日程了.

@nuk 性能还是有很大损失的,PHP8.0 的性能大约是 BPC 的 4 倍,详见: https://www.workerman.net/a/1576 **10.关于性能**部分

@JaguarJack 不明白单文件是什么意思.现在的编译结果就是一个可执行文件,只是不同平台 link 的基础类库稍有不同.

@haha512 上传的文件还在 wp-content/uplaods/ 目录下,静态 html 如果是事先生成的,可以直接编译到二进制里,如果是运行期间动态生成的,原来放哪儿还放哪儿.

BPC 并不改变 PHP 代码的运行逻辑,只是编译成二进制后,原来你要 scandir 来看安装了哪几个主题,glob 来看安装了哪些语言包,这些逻辑肯定要调整.

@zekeluii 编译 laravel 够呛,目前 BPC 还不支持 trait.

@cwcc 并且转换出来的.scm 和.c 都是可查看的. 另外基于 scheme,写 PHP 扩展容易多了.

@CodeCodeStudy 是的,彻底改变 PHP 项目的交付方式. 单就 wordpress 而言,插件和主题也可以以.so 的方式交付.

@millken BPC 不支持跨平台编译,这只是实现时的简化选择而已.

BPC 将 php 编译成 bigloo scheme,而 bigloo scheme 是支持多平台并且能够 Cross Compilation 的.如果愿意,肯定是能做到的,但目前还没到那个阶段.

1. http://www-sop.inria.fr/indes/fp/Bigloo/index.html
2. http://www-sop.inria.fr/indes/fp/Bigloo/manual-chapter33.html

@jry 所以这时间有测试用例保障是非常重要的.一个黑盒子,给定同样的输入,给出同样的输出,内部怎么改都没什么可怕的.要是没有完善的测试用例,做起来心里肯定不踏实.

@happy321 BPC 也是重新实现了每一个扩展,只不过扩展开发简单一些,并且还有 php 扩展源码做参考.

BPC 不以性能为第一目标,能和 php 持平就可以了,但和 php 的兼容性一定要高,这样能在 php 环境下做开发调试,只是发布时拿 BPC 编译一下.

@mrpzx001 BPC 的核心目标是两个,一是源码保护,二是软件授权.

另外 BPC 重新实现了 php 的 runtime 和每一个扩展函数,部署出去时,服务器上是没有 php 运行环境的,就相当于是 C 写的程序,只不过是 php 转译的.但是从外部看,所有表现都很像 php.

@learningman

没有尝试编译过,但应该没问题. 插件可以编译成一个个的.so, 然后调用 dl()函数加载进来.
因为 BPC 的目标是源码保护,而不是性能,所以 php 的动态特性该有的都实现了.

@jry

除了非常简单的 php 程序,不可避免都要进行一些修改,毕竟编译后是一个二进制包括了所以逻辑,编译前是分目录和文件的.

不过我看 https://github.com/top-think/framework 只有 tests 里有一个 trait, 当然 think-orm 里多一些.
但是简单的情况下, trait 就是在 use 的位置插入 trait 的代码而已, 所以调整起来应该还好.

@jry 我没用 thinkphp 开发过项目,对 thinkphp 不熟.现在来说是要调整 thinkphp 的代码来让 BPC 编译成功.如果你手里有真实的项目需求,我可以提供一些帮助.

@chenjia404 目前整个 BPC 就我们自己的项目在用,之前都是 apache+mod_bpc 发布的,很快线上都会升级成 nginx + althttpd 形式的,毕竟只有一个文件,部署起来方便很多.

我们的项目大多是 toB 的,不方便分享.近期有一个刚上线的 toC 微信小程序"中实国际集团",你可以微信里搜一下,后端就是 BPC 编译的,在线聊天是 BPC 编译的 GatewayWorker/workerman.

@rm0gang0rf 举个例子,你想编译哪个框架?

能否编译一般考虑两方面:

1. 框架用到的 php 语言/语法特性 BPC 是否支持.

BPC 不支持 trait,generator,reflection.比如 thinkphp,我 grep 了一下 trait,发现 think-orm 目录下有一些文件用到了 trait,那么要想编译 thinkphp 可能需要的改动就要大一些.

2. 框架用到的扩展 BPC 是否已经实现了.

一般来说,BPC 的扩展开发相比 php 扩展要容易很多,所以扩展未实现不是什么大问题.但是如果框架用到的扩展 BPC 还没有实现,显然你自己编译不了.需要 BPC 实现了扩展之后才能编译成功.

其它的一般都是些小改动,比如__DIR__ __FILE__之类的.

另外,如果框架有比较完善的 phpunit 测试用例的话,会有非常好的质量保障.

以下几个项目可供参考,你可以浏览 git commit log,看下为了 BPC 编译需要做哪些调整:

1. https://github.com/bob-php-compiler/zf1
2. https://github.com/bob-php-compiler/bpc-workerman-4.1-branch
3. https://github.com/bob-php-compiler/bpc-GatewayWorker-3.x-branch