支持的操作系统

目前仅在下面的操作系统上进行编译、运行、测试:

  • Windows

  • linux

  • macosx

  • bsd like

如果您使用到不是上述内核的操作系统, cf可能无法正常编译运行.

确认所需依赖库

  • libev(>4.24)

  • lua(>=5.3)

  • openssl/libressl(支持SSLv3与TLS)

安装方法

推荐开发者在宿主机上自行编译依赖库与框架, 这通常情况下会让其运行的更加流畅并且调试代码非常便利.

当我们将框架代码文件下载到本地后需要配置一系列依赖才能让它正确的进行编译, 这些依赖库通常存在于大部分系统的包管理工具内.

框架提供了build.sh脚本文件自动安装lua5.3与libev4.25依赖, 但是很不幸的是脚本的依赖安装需要包管理工具安装执行依赖库.

如果您使用的是Linux操作系统, 可以通过系统自带的包管理工具(apt/yum)安装. 如果您使用的是OSX或者BSD, 那么(brew/pkg)等工具是您唯一的选择.

  • libtool

  • aotomake、autoconf

  • gcc、clang

  • make

  • readline-devel

  • git

  • openssl-devel

1. 利用Build.sh安装

使用sh build.sh命令进行安装, 它会创建一个build目录并自动下载libev 4.25与lua 5.3.5并进行编译. 执行完毕后会自动删除下载到文件.

这种执行模式是固定的. 当您需要一个稳定的版本不跟进cf的最新分发版的时候, 这通常会让您fork的一个分支处于一个较为稳定的状态.

如果执行过程一切进展顺利, 头文件与库文件会自动放到/usr/local/lib与/usr/local/include. cf在运行的时候会自动找到它们.

反之, 您需要再看一次上面的建议并且排查是否漏过了某些库文件的安装. 这在网络通畅的环境下, 一般构建速度是比较快的.

当构建完成, 我们就可以开始编译框架源码了. 你有以下几个命令可选:

  • make build, 使用这个命令将会开始逐步编译cf内的源码、内置库、第三方库.

  • make clean, 清除之前编译过后的产生的可执行文件与动态库文件.

  • make rebuild, 使用这个命令将会清除之前编译过后产生的可执行文件与动态库文件并且重新编译一次; 效果等同于make clean && make build.

当您运行make build之后, 如果遇见错误将会指出错误产生的原因. 如无错误, 在当前根目录下将会出现./cfadmin可执行文件.

2. 自行安装依赖

如果您选择自行安装所有依赖, 作者对您本身的能力予以肯定. 安装开发环境是一个苦力活, 但是也是开发者所必须历经的一个步奏.

编译安装通常情况好处包含但不限于:

  • 优化框架运行时.

  • 定制化依赖库版本.

你需要按照前面提到过的最小依赖版本自行下载libev与lua, 这通常需要自行到相关软件的社区网站进行下载.

编译libev的步奏如下:

  • 运行sh autogen.sh, 这个脚本会根据当前系统环境生成配置脚本.

  • 运行./configure —prefix=/usr/local, 脚本开始检查系统环境并且生成makefile文件.

  • 运行make && make install, 编译libev并且将编译完成库文件与头文件放置到/usr/local相关目录下.

编译lua的步奏很简单! 首先运行make命令, 他就会列出目前支持的编译系统环境. 通常如下所示:

  1. Please do 'make PLATFORM' where PLATFORM is one of these:
  2. aix bsd c89 freebsd generic linux macosx mingw posix solaris
  3. See doc/readme.html for complete instructions.

在找到合适您的环境后, 使用make PLATFORM MYCFLAGS=-fPIC && make install命令进行编译与安装.

这样会让依赖库具有动态链接库的符号导出性质, 框架需要这样的性质导出符号让libcore.so能自动链接其它"动态库".

如果编译出现问题, 通常是缺少readline的问题. 您可以通过系统包管理工具安装readline后重新执行上述命令即可.

安装依赖期间产生的编译器警告

这样的警告一般情况下是无害的. 受限于不同的编译器实现, 警告的消除通常难以避免.

为框架定制内存分配器

cf框架使用系统默认的内存分配器, 这通常情况下能运行的较为稳定. 但是这样也是难以抵挡一些geeker对定制化的需求.

cf框架内部适配了一些业内较为知名度较高的内存分配器, 如: jemalloc、tcmalloc. 经过简单的测试后发现, 实际运行效果在5%~10%之间浮动.

cf框架默认情况下没有开启, 这需要您拥有自行定制框架的makefile的能力. cf的makefile是以最简单易懂的方式编写, 所以修改非常简单.

Windows 安装

cf内部依赖与设计就决定了它在Windows平台的支持本身就是十分有限的, 这也是在早期的版本中没有考虑对Windows提供支持.

从哲学上来说: 我们应该使用Unix like平台开发Unix like应用. 但是仍有一大部分用户在咨询Windows平台移植到问题.

这并非偶然! 毕竟硬件条件与开发环境本身就是对开发者的一种要求, 而作为框架设计者将这些条件强加于开发者显然会造成一定的阻碍.

为了让Windows原生平台能运行, 我们至少需要解决下面这几个问题:

  • API差异;

  • 路径分隔符差异;

  • 系统调用差异;

移植的方式有2种: 1. 重写实现; 2. 增加系统兼容层; 而第一种显然会引起不必要的开发难度与稳定性问题, 那么只能寻找第2种解决方案.

所幸借助msys2内置的Cygwin完成了这个难题. Cygwin致力于在Windows平台模拟Unix Like环境, 基于POSIX提供的API实现来减少跨平台的难度.

众所周知! 任何事件驱动(框架)库都需要依赖一个后端backend来提供事件驱动与超时机制的功能; 平台提供的高性能后端能提高cf框架的运行效率.

框架内部会自动判断当前支持的后端, 默认将SELECT置为通用的(也是最慢的)事件驱动方案. 而SELECT也是移植到Windows平台的唯一选择.

不只如此! cf的内置库通常需要将跨平台导致的问题屏蔽, 而这其中就包括dns库读取hosts与resolv.conf文件引起的问题;

默认情况下, 内置的dns库会解析/etc/resolv.conf文件. 通过读取操作系统配置的dns服务器IP用来提供异步dns解析工作.

它不会尝试去解析Windows的hosts文件, dns库只能通过固定的dns服务器IP来完成解析工作. 这通常会让dns解析速度变慢(2x).

通常情况下, cf框架会使用dual-stack套接字来完成IPv4-IPv6 Map的兼容. 在Unix Like环境下通常我们什么都不必关心(默认开启).

而在Windows环境下就需要设置IPV6_V6ONLY为0来手动关闭, 否则会就会引起导致IP路由不可达的问题. 这是我们所不希望见到的.

当框架解决完上述问题后, 我们只能checkout一份branch来单独作为windows移植到分发版分支. 它将会随着每次更新而提供一份二进制分发版.

您只需每次到release下载二进制文件分发版来进行开发即可.

其它问题

如果您在安装或使用时遇到一些问题无法解决, 请参考Q&A获得帮助.