Windows上配置Code::Blocks + wxWidgets

27号晚上我问一个做共享软件的朋友Lazaru(基于FreePascal的跨平台IDE,类似于Delphi)做桌面软件如何,他推荐用Code::Blocks,说Nightly Build已经很稳定,正式版很快就发布了,接着果然28号就发布了正式版。

本文内容来自Code::Blocks wiki上的WxWindowsQuickRef,本文内容并非按照原文完全逐字逐句的翻译。

Code::Blocks是一个跨平台的C++IDE,支持Windows、Linux、MacOSX。同时他还支持各种不同的编译器,如GNU/MinGW C/C++,VC++ 6.0/2003/2005/2008,Borland C++,Digital Mars等等各种不同的编译器。

经过14个组员长达2年对Code::Blocks的全部重写,终于发布了正式版8.02,这个版本更包括了对构建基于wxWidgets的跨平台GUI程序的支持,堪比Visual C++。

wxWidgets则是一个十分优秀的跨平台的GUI框架,用其编写的C++应用程序可以十分方便地迁移到不同的系统上去。

Code::Blocks + wxWidgets两个同是支持跨平台的IDE和框架,使得跨平台的编程非常方便。然而Code::Blocks虽然包含了对wxWidgets的支持,但是却没有包含wxWidgets的构建环境,我们必须手动进行配置。另外,Code::Blocks有一个安装包包含了MinGW的编译器,如果使用别的编译器,同样也需要自己进行相应的配置。

前提准备

编译器

你至少应该正确安装了免费的MinGW/GCC编译器或者是某种微软的编译器Express editions是免费的,但是你还需要安装Platform SDK)。如果是用MinGW/GCC,至少要准备gcc-core、gcc-g++、binutils、w32api以及mingw32-make包;同时,确保包含编译器可执行文件的目录(一般是C:\MinGW\bin)在Windows的PATH环境变量中。

如果选择MinGW/GCC编译器,可以在直接选择包含MinGW的Code::Blocks安装包,见下一节。

最新版的Code::Blocks

请下载最新的8.02发布版。尚未选择编译器可以选择包含MinGW的安装包

wxWidgets

你可以选择下载wxWidgets的源代码然后自己进行构建,或者是直接安装预编译的wxPack。

wxWidgets源代码

安装包较小,可以根据自己的需求进行自定义构建,但是需要花费长时间进行编译。如果不清楚编译选项,可能导致无法成功配置Code::Blocks。

目前推荐的wxWidgets的版本是2.8.7。点击此处下载wxWidgets 2.8.7源代码Windows安装包 (wxMSW-2.8.7-Setup.exe; 12.0 MB)。你也可以检查一下wxWidgets的下载页面看看有没有更新的稳定版下载。强烈建议你将代码安装到不带空格的路径中。必须保证盘中至少有300MB的剩余空间。

wxPack

虽然安装包达200MB,全部安装需要3G,但是包含了预编译的所有可能用到的库文件,而且包含VC和GCC的两种版本,可以不用去考虑构建选项了。

当前wxPack的稳定发布版是 v2.8.7.03,基于 wxWidgets 2.8.7。点击此处下载 wxPack v2.8.7.03 (wxPack_v2.8.7.03.exe, 236.9 MB)。你也可以查看wxPack下载页面看看有没有更新的稳定版下载。强烈建议将wxPack安装到没有空格的路径中。如果你选择只MSVC版本,应保证至少有700MB的剩余空间;如果只选择MinGW/GCC版本,则应保证至少有2.2GB的剩余空间。

提示

如果磁盘使用了NTFS格式,可以开启文件压缩功能,上述的目录在压缩后可以减少50%的空间占用。

编译wxWidgets

使用wxPack则可以跳过这一步。

打开命令行(在开始菜单中点击“运行”,输入cmd并回车)。如果使用的MSVC,你可以使用特定的用于设置环境变量的命令行。如果你使用的MSVC版本还要求你单独下载Platform SDK,确保全部包含了标准编译工具和Platform SDK中要用到的环境变量。

转到wxWidgets的构建目录,其中<wxWidgets>是源码所在路径,通常是C:\wxWidgets-2.8.7

执行构建命令,MinGW/GCC推荐的命令是:

MSVC推荐的构建命令是:

这个过程需要花很久,快的机器大概30分钟可以完成,慢的可能就需要几个小时了。

如果使用的GCC的版本较新,构建过程中可能会出现大量的警告。这样会明显导致构建过程变慢;你可以将错误信息重定向到文件中,在上述命令后面添加2> err.log,也可以通过2>nul直接禁止警告信息。

其中关于BUILD、SHARED、MONOLITHIC以及UNICODE选项的解释,请仔细参考文章后面关于wxWidgets的构建参数的解释,这些参数十分关键,他们直接定义了你所使用的基本的wxWidgets开发环境。你必须严格按照你的编译参数设置Code::Blocks的配置向导。

在Code::Blocks中创建wxWidgets项目

在Code::Blocks的起始页面中,选择“Create a new project”,也可以在File菜单中,选择“New” -> “Project…”。

找到并选择“wxWidgets project”,并创建,接下来会出现一个向导帮助进行wxWidgets项目的配置:

  1. 第一个页面是简介,可以选择以后跳过。
  2. 选择你要使用的wxWidgets版本。如果你是按照本文的过程配置的,那么你应该选择“wxWidgets 2.8.x”。
  3. 设置你的项目的名字的位置。
  4. 输入作者的信息(非必要)
  5. 选择自动代码和文件生成的选项。
  6. 选择wxWidgets的位置。强烈建议在此使用全局变量:输入“$(#wx)”(不包含引号)。如果你还没定义这个全局变量,那么全局变量对话框会出现,在Base Path中,选择你的wxWidgets安装路径。其他路径可以不用填。
  7. 为你的项目选择debug/release配置。推荐至少选择debug配置。
  8. 选择你的wxWidgets构建选项。必须和你构建wxWidgets时所使用的选项一致!如果你按照本文之前的方式构建的,应该将“wxWidgets Library Settings”下的全部三个选项选中。如果用的是wxPack,由于wxPack包含了各种不同的版本,所以你只需要选择你需要的选项。这个页面的另一个设置和wxWidgets的构建选项没有关系,你可以按照喜好来选择。如果,出于某种原因,你想使用调试版本的wxWidgets构建,选择“Configure Advanced options”然后在下一页选择“Use __WXDEBUG__ and Debug wxWidgets lib”。
  9. 如果需要,选择额外的库。一般应用的话应该无须选择其中任何一个。

构建并运行程序

接下来,就可以选择“Build and run”(F9)对程序进行构建并运行了。如果顺利,你的wxWidgets应用程序就会出现。如果出现了什么问题,你可以参考后面的常见问题。

wxWidgets编译选项简介

BUILD

BUILD控制wxWidgets构建调试版本(BUILD=debug)或者是发布版本(BUILD=release)。绝大多数情况下你只需要wxWidgets的发布版本就可以了,因为你应该不想要去调试wxWidgets自身,同时你依然可以通过链接wxWidgets的发布版本来构建你自己的程序的调试版本。

  • 调试构建wxWidgets会创建带有”d”后缀的库,例如”libwxmsw28d.a”、”wxmsw28d_gcc_custom.dll”。
  • 调试构建wxWidgets会在wxWidgets库的输出目录中创建”mswd” 或者 “mswud” 目录。
  • 发布构建wxWidgets创建的库没有”d”后缀,例如”libwxmsw28.a”、”wxmsw28_gcc_custom.dll”。
  • 发布构建wxWidgets会在wxWidgets库的输出目录中创建”msw” 或者 “mswu” 目录。

SHARED

SHARED控制wxWidgets是构建DLL(SHARED=1)还是静态库(SHARED=0)。利用构建的DLL,主程序构建时间较快,可执行文件更小。但是可执行文件加上wxWidgets DLL的总大小更大,但是不同的可执行文件可以使用同一个DLL。

  • wxWidgets的DLL构建会创建导入库(如 libwxmsw28.a)以及DLL文件(如wxmsw28_gcc_custom.dll)。你必须在发布你的程序的时候包含这个DLL。
  • wxWidgets的静态构建只会创建静态库(如 libwxmsw28.a),发布的时候也无须包含wxWidgets的DLL。

MONOLITHIC

MONOLITHIC控制是构建一个单一的库(MONOLITHIC=1)还是多个组件库(MONOLITHIC=0)。使用单一构建,项目的设置和开发会更加简单,如果你同时使用DLL构建的话,你只需要分发一个DLL文件。如果使用非单一构建(multilib),会构建出多个不同的库同时你可以避免将整个wxWidgets的基本代码链接到主程序,就可以去掉不需要的库。同时你也必须确保你选择了正确的组件库。

  • wxWidgets的单一构建仅会创建一个wxWidgets导入库(如libwxmsw28.a)以及一个DLL(如wxmsw28_gcc_custom.dll)。
  • wxWidgets的多库(multilib)构建会创建多个导入库(libwx28_base.a等)以及多个DLL文件。
  • 无论何种wxWidgets构建,都会创建额外的静态库(如libwxexpat.a、libwxjpeg.a等)。这些库对于wxWidgets的DLL构建一般是不需要的,但是当使用静态构建的时候,则是必须的。

UNICODE

UNICODE控制wxWidgets以及你的程序是否使用支持Unicode的宽字符串。大多数Windows 2000或更高系统上的应用程序都应该支持Unicode。早期的Windows版本不一定有Unicode支持。你应该总是使用wxWidgets的_("string")_T("string")宏来确保硬编码的字符串编译时是正确的类型。

  • wxWidgets的Unicode(UNICODE=1)构建将会创建带有”u”后缀的库,例如”libwxmsw28u.a”、”wxmsw28u_gcc_custom.dll”。
  • wxWidgets的Unicode构建会在wxWidgets库的输出目录中创建”mswu”或”mswud”目录。
  • wxWidgets的ANSI(UNICODE=0)构建创建的库没有”u”后缀,例如”libwxmsw28.a”、”wxmsw28_gcc_custom.dll”。
  • wxWidgets的ANSI构建会在wxWidgets库的输出目录中创建”msw”或”mswd”目录。

常见问题

出现类似于”wx/setup.h: No such file or directory”的错误

你在构建选项中缺少了很重要的编译器搜索路径。首先确认你是否在运行wxWidgets项目向导的时候正确选择了wxWidgets的构建配置。如果重新运行向导并配置依然无效,那么打开你的项目的构建选项并给编译起的搜索路径中添加”$(#wx.lib)\gcc_dll\mswu“(这里假设是一个单一的Unicode DLL构建)。

出现类似于”cannot find -lwxmsw28u”的错误

构建选项中的链接库错了。首先确认你是否在运行wxWidgets项目向导的时候正确选择了wxWidgets的构建配置。如果重新运行向导并配置依然无效,确定你构建了什么库,并相应在构建选项中调整库的名字。

利用SSH通道加密网页浏览

更详细的介绍可以查看 Geek to Live: Encrypt your web browsing session (with an SSH SOCKS proxy)

我们普通的HTTP链接都是以明文进行传输的,信息非常容易被截取。例如,通过公共的无线热点上网、在公司要绕开网管或防火墙浏览某些页面。那么如何才能对普通的HTTP传输进行加密呢?

SSH为我们提供了这些便利。因为他具有内置的socks代理,可以在本地建立一个服务器,然后通过一个远程的可信SSH服务器来访问网络。

Windows可以采用Cygwin + OpenSSH,这个需要一定的配置,也可以使用CopSSH这个已经帮你配置好的安装包。

接下来就可以在控制台中通过以下指令来启动我们的本地代理:

接下来程序就会要求输入密码,接下来就可以使用了。

其中-N参数表示运行后不转入后台,而是占用控制台,这样我们可以方便地通过Ctrl+C来终止,-D就是表示在后面所跟的端口上建立socks代理。

使用方面,推荐使用Firefox的FoxyProxy,可以配置为仅部分地址使用代理。

最后,如果链接速度较慢的话,我们可以使用-C选项来开启传输的gzip压缩:

你搜我搜

Song同学利用空余时间和复旦某位神秘牛人搞了个关于汽车的垂直搜索引擎——你搜我搜

你搜我搜是一款以汽车相关信息为检索对象的专业搜索引擎,是涵盖新车报价、二手车信息、汽车评论、汽车新闻、汽车图片等汽车相关信息的搜索平台。你搜我搜融合了信息检索、自然语言处理等多项关键技术,为用户提供汽车领域的一站式搜索门户。

2007年5月公司在上海创立,并于当月获得第一笔风险投资,开始快速发展。公司专注于垂直搜索平台的开发,拥有的深厚自然语言处理和搜索引擎技术背景,你搜我搜具有智能识别、即时索引、海量信息处理等技术特色。我们以用户需求为中心,努力提供准确、迅速的信息。

其中最具有技术含量的关于汽车的“评论”搜索,可以对被搜索的汽车,分别显示正面和负面的评论,便于用户进行比较。

希望Song同学能继续把这个网站做好!

Redmine

Redmine是基于Ruby/Rails的一个项目管理软件。比较类似的则是基于Python的Trac,相比之下,Redmine有很多优势:

  • 简单的安装、配置和部署
    Redmine利用rake、rails的db migration安装很方便,Trac则要用到命令行的trac-admin进行配置,以及每个项目有单独的ini配置文件
  • 方便的用户和权限管理
    Redmine支持多LDAP认证、还支持用户自己注册,然后通过邮件激活。Trac依然需要使用trac-admin来配置,而且默认的用户登录方式是HTTP验证,基于cookie的还需通过插件实现
  • 基于Web的多项目管理
    Trac创建和配置新项目需要使用trac-admin
  • Ajax
    Redmine通过Ajax在某些方面提供了更好的用户体验,如代码仓库的浏览
  • 多语言
    包括简体中文
  • 多种SCM
    包括SVN、CVS、Darcs、Mercurial、Bazaar,是通过调用它们的可执行文件来实现的。

trac的很多功能都需要通过trac-admin在命令行方式下进行配置,不易上手,这方面Redmine则十分方便。

其实功能方面,Redmine更多地是模仿Sourceforge的功能,比如新闻、文档、下载等,目的是建立这种适合团队协作的平台。我估计以后Rubyforge可能会迁移到Redmine上去。

Linux 上配置 Nginx + Mongrel cluster

Nginx不仅是一个小巧且高效的HTTP服务器,也可以做一个高效的负载均衡反向代理,通过它接受用户的请求并分发到多个Mongrel进程可以极大提高Rails应用的并发能力。下面介绍一下如何在一台服务器上配置Nginx + Mongrel cluster。

获得Nginx方法可以参考前一篇配置Nginx+PHP5 FastCGI的文章,这里我们假设大家是通过自己编译,并配置了默认的编译的参数,此处使用的是Nginx 0.5.x版。

配置Mongrel cluster

我们还需要获得Mongrel和其Cluster插件(用来方便得启动多个Mongrel进程),如下通过gem进行安装:

然后建立mongrel_cluster的配置文件。进入Rails应用即你的程序的根部目录(以下假设/usr/rails),运行:

然后mongrel_cluster便会在config目录下生成一个mongrel_cluster.yml,内容如下:

我们可以通过修改其中的设置来更改mongrel_cluster的运行,这个范例配置省略了一些其他参数,具体的参数的含义如下:

  • address: 指定绑定的地址
  • port: 指定mongrel_cluster所运行的mongrel进程从哪个端口开始绑定
  • servers: 指定同时运行多少个mongrel进程,结合port参数,就是表示port到port+servers-1(含)的端口将被使用
  • environment: 指定Rails运行的配置环境
  • user: 指定mongrel进程以什么用户的身份运行
  • group: 指定mongrel进程以什么组的身份运行
  • cwd: 指定mongrel运行的根目录
  • log_file: 各个mongrel进程的输出日志的位置,相对于cwd的目录,会在文件的扩展名之前加上各进程对应的端口号
  • pid_file: 各个mongrel进程的pid文件的位置,相对于cwd的目录,会在文件的扩展名之前加上各进程对应的端口号

大家可以根据自己的具体情况进行修改。以下是一个完整的mongrel_cluster.yml配置文件:

接下来便可以启动mongrel_cluster了,以下是控制mongrel_cluster的命令:

配置Nginx负载均衡反向代理

利用nginx的upstream指令配置哪些服务器需要进行负载均衡。在这里也可以说直接说告诉nginx mongrel_cluster在哪些地址和端口上,按照上面的mongrel_cluster的配置,在nginx中应该这样写:

upstream指令后面的mongrel指定了这批上游服务器的的名称,大家可以使用别的名字。每个server指令指定了一个服务器,server指令还支持别的参数可以设置重试次数和超时时间以及不同服务器的权重。

接下来配置nginx在接受哪些http请求时转发到mongrel cluster,因为nginx处理静态文件的速度远远高于mongrel,所以一般当请求的路径不存在的时候才将请求转发到mongrel cluster:

整个Nginx的配置文件的范例请参考:http://wiki.codemongers.com/NginxConfiguration

然后重启Nginx,配置便成功了.

Ruby 1.9.0 发布

来自Ruby官方网站的最新消息,Matz已经发布了1.9的开发版本作为献给大家的圣诞礼物。

1.9的性能较1.8有大幅提升(请参考相关测试结果),并且添加了大量新的语言的特性

这无疑对于Ruby爱好者是一个福音,但前不久刚发布Rails 2.0还不能完全正常运行于Ruby 1.9之上,包括诸如Mongrel之类的其他组件,所以在很长时间内Ruby 1.8将仍然是主流的平台。不过相信Ruby社区和相关社区的朋友们会一起努力,使这个迁移快速而顺利地完成(就像当年Python 2.5发布的时候)

Nginx的WordPress配置

WordPress是一个非常流行的Blog系统,它可以利用Apache的mod_rewrite来实现URL的静态化。安装好的WordPress在配置了持久链接之后,会在网站的根目录下(如果可写)生成一个.htaccess文件,这个文件可以指示Apache如何进行URL重写(如果服务器配置为允许使用htaccess的指令的话),它的内容如下:

这个文件的意思就是,如果当请求的文件不存在,那么把请求内部重定向到/index.php。WordPress会自己分析请求的URL,来判断显示哪个页面。

在上次配置了Nginx+PHP之后,由于Nginx不支持Apache的.htaccess文件,要实现持久连接静态化,我们必须手工配置Nginx的文件。首先找到Nginx的配置文件,默认编译后的配置文件在/usr/local/nginx/conf/nginx.conf;Ubuntu通过包安装的配置文件位于/etc/nginx/nginx.conf,也可以编辑vhost的配置文件,放在了/etc/nginx/sites-available下。

以下是基本的配置(Ubuntu下的范例):

还可以有很多种不同配置方式,例如不改写所有包含wp-的url等。此配置考虑了目录下的索引文件index.html和index.php。-f指令表示测试文件是否存在(不考虑文件和目录的区别),!-f则表示不存在。注意在重写url到index.html后面有个break,而重写到index.php后没有break。因为html文件不需要任何额外工作可以直接发送到客户端,所以重写规则在这里终止,下面就直接让nginx发送文件。而.php文件需要进一步发送到fastcgi进程来运行,Nginx会继续判断该文件符合第二个部分location ~ .*\.php$的规则,并进行FastCGI的转发。

大家可以将以上内容保存为wordpress.conf,然后在自己的vhost配置,即server节中应用该配置文件,例如(以下为Ubuntu进行的配置):

接下来让Nginx重新载入配置文件,便可使用WordPress的持久链接了。

Linux 上配置 Nginx + PHP5 FastCGI

Nginx是俄罗斯人编写的十分轻量级的HTTP服务器,以事件驱动的方式编写,所以有非常好的性能,同时也是一个非常高效的反向代理、负载平衡。其拥有匹配Lighttpd的性能,同时还没有Lighttpd的内存泄漏问题,而且Lighttpd的mod_proxy也有一些问题并且很久没有更新。

因此我打算用其替代Apache应用于Linux服务器上。但是Nginx并不支持cgi方式运行,原因是可以减少因此带来的一些程序上的漏洞。那么我们必须使用FastCGI方式来执行PHP程序。

下面是我成功地配置Nginx + PHP5 FastCGI的过程

继续阅读“Linux 上配置 Nginx + PHP5 FastCGI”

VirtualBox + gOS

不知多久之前听说了gOS,当时隐约记得有人误传说他是Google推出的操作系统,而且也看到了这个操作系统界面上有相当多的Google应用,后来澄清了其实gOS代表的是green OS的意思,和Google毫无关系(看他的主页底部的声明),主要的目的是为了一个廉价PC而设计的操作系统,所以整合了很多Web应用的快捷方式。

其实这些我都不关心,我最关心gOS的地方,其实是他使用了Enlightenment DR17(简称e17)作为他的窗口管理器和桌面环境(也就是把Gnome给替换掉了,其实早在GNOME 1.0的时候,它也整合了Enlightenment作为其窗口管理器,只是后来改成了Metacity),而且是一个非常轻量级的桌面环境。早在3年前,e17便有了一些测试版本,我当时在Fedora Core 3上安装了测试版,完全被其华丽的界面给震撼了,看过了e17的界面,我觉得完全不输给MacOS的任何版本。时隔三年,终于e17顺利发布,而且能够有一个Linux发行版预设了e17,尤其gOS又是基于现在我最喜欢的一个Linux发行版Ubuntu,实在是太完美了!

gOS with e17gOS为e17做了一套自己的最简化的主题。如果有哪位朋友装了gOS,一定要尝试一下e17默认的主题 “bling”。

唯一的遗憾是,gOS和e17在默认情况下对国际化的支持并不是太好,默认的桌面字体非常小 ,虽然很适合西方字幕,但对于中文字就不行了,默认的终端窗口也显示中文字体都是方块,不过经过适当的调整,还是可以正常显示的。