@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

@happy321

BPC 已经成功编译了 workerman 和 GatewayWorker,并且我们自己基于 GatewayWorker 的聊天应用已经发布到了线上,bpc.dev 上的那个 online compiler 也是用 wokerman 做的.

但是普通的 web 项目和 workerman/webman 还是有区别的,编译成 althttpd 的 php 代码里,逻辑和使用 php-fpm 或者 mod_php 是一样的,exit/die 该怎么用就怎么用,echo/var_dump 也一样会显示在页面里,而不是终端上.

由于编译的关系,每次请求当然不需要解释 php 源码了,并且 class 的定义也可以做到只加载一次,相当于 workerman/webman 说的常驻内存了.

这样,我们可以正常写 php 页面,经 BPC 编译后,又能获得额外的一些好处.

@0o0O0o0O0o

今年是 BPC 编译器开发的第三年,如果不想着追赶 PHP 版本升级的话,编译器自身已经相当稳健了.
BPC 的重点在于它改变了 PHP 项目的交付方式,完善解决了源码保护和软件授权的问题.

@veike

我个人是非常喜欢 PHP Scheme 这种弱类型语言的,对强类型语言没什么兴趣.
再说做一个项目只是单纯玩玩很难持续下去.BPC 即使不推广商用,仅在我们公司内部,也有足够的应用场景,这样才能持续搞下去.

@Echoldman 因为当时刚开始开发 BPC 的时候,用的是 ubuntu 18.04,而 ubuntu 18.04 上默认的 php 版本就是 php 7.2.19.

@lifeintools 所以源码保护的需求是有的,BPC 转译的方案可以 100%保护源码,license 机制可以实现强有力的软件授权.

我们自己也正是有这样的需求,才开发了 BPC.

当然 BPC 和 PHP 只能做到高度兼容,不能 100%兼容,毕竟 BPC 相当于重新实现了 PHP.

@IdJoel 10 多年前就有人说我们公司是个皮包公司,过不了几天就挂了,现在我们还活的好好的,他们却挂了.

另外大企业有法务,人家不需要这东西.

@IdJoel 也不知道 zend guard, ioncube, swoole compiler 有没有客户

@happy11 应该问题不大.

因为最近公司有个项目需要在线聊天,调研了一圏决定用 GatewayWoker,所以才实现了 event 扩展,之前没解决的一些小问题也都解决了,本地开发测试过程中还没有发现什么问题,下个月项目就会上线.

等项目上线运行稳定了,会写个文章详细介绍下 workerman 和 GatewayWorker 的编译和应用.

另外, https://bpc.dev 上 BPC Playground 连接的 online compiler 其实就是用 wokerman 实现的一个 websocket server, BPC 静态编译的,不是用 php 运行的.

@jason56 虽然理论上可行,短期内比较困难,我们自身也没有 swoole 的相关需求.

@CodeCodeStudy 是的,第一目的就是源码保护

我多年前过了一遍 linux 内核从加载到 init 进程启动的代码,做了一些笔记,供参考.

http://heguangyu5.github.io/my-linux/html/index.html

虽然当时不是所有地方都搞明白了,但之后操作系统,进程,线程,内存,epoll 什么的,都不再神秘了.

之前我写过一本电子书 <<PHPUnit in Action --- The Easy Way>>, 供参考.

https://www.zhihu.com/column/c_1269564826948546560