麻烦不断,搞定一个又来一个。
安装完SIP,打开Visual Studio x64 Win64 Command Prompt (2010),切到PyQt5.0源码目录下,运行configure.py,本以为能顺利进行,结果如下图所示:
查了一下,说是PyQt源码不包含Qt部分,需要单独下载,qt-opensource-windows-x86-msvc2010-5.5.0.exe
下载完成后再次运行configure.py,依旧报上述错误,看来需要手动把C:\Qt\Qt5.5.0\5.5\msvc2010\bin到环境变量PATH里
又一次运行configure.py,好消息是不报上面的错误了,坏消息是报下面的错误:
照提示又加上--verbose参数运行了一次,得出详细错误信息
看来又是32位nmake和64位nmake的问题,64位不行果断启动32位 Visual Studio Command Prompt (2010)
运行configure.py,错误信息如下:
好你个老妖精,没完没了了。大意是说PyQt5的协议和Qt的协议不兼容。
PyQt5 is dual licensed on all platforms under the Riverbank Commercial License and the GPL v3. Your PyQt5 license must be compatible with your Qt license. If you use the GPL version then your own code must also use a compatible license.
PyQt5, unlike Qt, is not available under the LGPL.
再引用别人的调查成果:
Qt 4.5中提供了三种授权协议,分别是GPL, LGPL和Commercial,可能很多人要问,为什么同样的一个产品要提供三种授权协议,什么情况下使用什么的样的授权协议最合适?在这里我就大致解释一下:
GPL全称是The GNU General Public License,是目前大多数的GNU程序和超过半数的自由软件使用的许可协议。GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用,但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。
GPL协议的主要内容是只要在一个软件中使用(”使用”指类库引用,修改后的代码或者衍生代码)GPL 协议的产品,则该软件产品必须也采用GPL协议,既必须也是开源和免费。这就是所谓的”传染性”。GPL协议的产品作为一个单独的产品使用没有任何问题,还可以享受免费的优势。
回到LGPL,LGPL的全称是 GNU Lesser General Public License,GNU 较宽松公共许可证,也是由协议是由自由软体基金会发布的许可证,是一个主要为类库使用设计的开源协议,和GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同。LGPL允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。
除了GPL和LGPL两种开源协议之外,Qt还提供了Commercial商业协议,Qt的商业协议是由Nokia定义的,由Nokia和购买方签订的,具有法律效应的Qt产品授权协议。 Commercial License相教与GPL和LGPL,对于商业客户提供了更多的灵活性,客户可以任意的修改Qt的源代码,开发商业软件,而不需要公开任何源代码。并且,在Commercial License中,我们还提供了技术支持服务。当然,商业授权协议是需要费用的。
到底什么时候需要选择GPL和LGPL呢?一个最显而易见的理由就是他们都是免费的,使用LGPL和GPL版本的Qt是不需要支付任何费用的,当然我们也相应的不会提供技术支持。如果你打算开发真正的开源软件,并希望使用者也可以保持开源,那么GPL是更好的选择,因为所有人,不论你自己还是将来基于你的代码进行再次开发都必须开源。如果你打算开发闭源(不开放源代码)的商业软件,那么LGPL则更适合,但必须满足下面两个条件:
1. 你的应用程序应该动态链接Qt函数库,并使你的应用程序与未做修改的LGPL库分开发布。同时必须确保使用者(接受者)知道应用程序使用了LGPL版本的Qt;
2. 如果你对LGPL版本的Qt进行了任何修改,并发布,则必须遵循LGPL 条款发布。任何使用者有权利得到这些修改(通常情况下是源代码),并且确保使用者可以通过这些修改自己生成相应你修改过的Qt版本。
相信到这里大家已经对Qt提供的这三种协议有了基本的了解,通常大家还会有一个疑问,就是基于这三种授权协议的Qt产品到底由多少功能上的区别,是不是商业版本的会更完整,性能更好一些?这里我可以负责任的说:99%的代码都是一样的,无论是GPL, LGPL还是Commercial,功能,性能都没有区别,唯一的区别就在于授权协议的不同。
还有一点需要说明的就是,由于LGPL是在Qt4.5这个版本里面才引入的,所以之前的Qt版本,4.4或者3.x的版本,并不提供LGPL协议,是不可逆的。同时未来发布的Qt版本,就一直会提供三种不同的授权协议版本。
PyQt采用的是GPL,Qt要与其兼容就必须采用GPL(当然二者都有商业版,不过屌丝宅男买不起,不考虑了。),意思就是哥前面下的Qt协议是Commercial 的,还得重下GPL的。
Qt官网给出了两种下载方式,一种是Online,一种是Offline,Online下载之前会问你几个问题,一路照着open source选,到最后提示你看看LGPL协议,并给出个下载链接,下载下来的文件并不是Qt,而是Qt的在线下载器,可惜的是总是超时,根本下不下来。
另外一种下载方式是Offline,官网给出符合我开发环境的只有Qt 5.5.0 for Windows 32-bit (VS 2010, 585 MB) ,之前安装的就是这个,执行configure.py的时候报协议兼容问题,所以我怀疑所有Offline下下来的都是Commercial协议,这条路也堵死了。
本以为又到瓶颈了,没想到偶然间看到CSDN一大哥也遇到这个问题,自问自答的说了句“自己修改configure.py骗过去了”,真是太有喜感了。虽然违反了开源协议,但这也都是被逼的啊,于是乎我打开configure.py,注释掉了2590行开始的下段代码:
# Common checks.
if introspecting and target_config.qt_licensee != 'Open Source' and ltype == 'GPL':
error(
"This version of PyQt5 and the commercial version of Qt have "
"incompatible licenses.")
然后启动Visual Studio Command Prompt (2010),切到PyQt目录,执行configure.py,又报错:
Error: Make sure you have a working sip on your PATH or use the --sip argument
to explicitly specify a working sip.
真心要崩溃了,不过还好不是什么大问题,因为之前已经成功安装过SIP了,打开python安装目录,看到sip.exe就在根目录下,也就是C:\Python34
把这个路径添加到PATH环境变量中(这里需要注意一下,添加完环境变量后需要先关闭Visual Studio Command Prompt (2010),然后再开启,否则依旧报这个错误),再执行configure.py,终于通过了,然后执行nmake,好吧,错误如下:
又是32位和64位的问题,切Visual Studio x64 Win64 Command Prompt (2010),我再试
好吧,连configure.py都报x86和x64的问题,看来还是得从Visual Studio Command Prompt (2010)下手
目测好像是python的问题,我安装的是64位的python,这里需要的可能是32位的,先睡觉,下午忙完再回来弄
后来证实的确是python版本问题,怒卸x64,换x86版本的python
启动Visual Studio Command Prompt (2010),切到PyQt目录下,执行configure.py,神奇的通过了~
然后再执行nmake,噩梦又开始了,错误如下:
谷歌了半天,毫无头绪,针对符号被多处定义的问题有人建议加上/FORCE:MULTIPLE参数,不过用惯了IDE的我完全不知道该加到哪里,配置编译安装三步configure.py、nmake、nmake install,没有可插足之地啊。难道要编译的时候自己写个makefile?麻烦死了。再就是另外还有一种猜测,难道是我下载的Python、Qt以及PyQt版本有问题?我看PyQt官网给的下载链接名是PyQt5-5.5-gpl-Py3.4-Qt5.5.0-x32.exe。本机Python3.4.3 x86,PyQt5.5.5,Qt5.5.0,应该有没有问题啊。这次真的是没有一点办法了,一会发个email给PyQt,看看能得到什么帮助不。
收到回复了,内容如下:
Before running configure.py rename the \path\to\qt\include\QtNfc directory to something like QtNfc-disable. Or use the provided binayr installer.
给出了两种解决方案,第一种说是重命名QtNfc的目录,不过我没有找到相关路径。
第二种让我用安装包装。我要是想用安装包装我至于费这么大劲吗……
不过第一种方法倒是提醒了我,反正我也用不到Nfc模块,不如就跳过它,不编译就是。于是翻看confiure.py,用Vim搜了一下QtNfc,一共有三处,全都注释掉,然后再namke,成功了。接着执行nmake install,搞定~
回头再来看一下,其实confiure.py第三处QtNfc所在的函数check_5_5_modules中的注释就已经在提醒,函数里面的两个模块有build不过的可能性。只可惜没有文档说明,要不在build之前就能发现这个问题,而不是出现问题后跟无头苍蝇一样一顿乱试。
def check_5_5_modules(target_config, verbose):
""" Check which modules introduced in Qt v5.5 can be built and update the
target configuration accordingly. target_config is the target
configuration. verbose is set if the output is to be displayed.
"""
check_module(target_config, verbose, 'QtLocation', 'qplace.h',
'new QPlace()')
check_module(target_config, verbose, 'QtNfc', 'qnearfieldmanager.h',
# 'new QNearFieldManager()')
再总结一下安装顺序吧
1.python3.4
2.SIP
3.Qt5.5.0
4.PyQt5.0
好了,用源码编译安装PyQt5到这里就全部结束了。文中详细记录了我的安装过程,很啰嗦,如果有人想参考安装的话,可能需要自己整理一下。再就是安装完后我发现,其实还是用安装包安装PyQt5方便省事功能又全,安装包带了很多实用的工具,而源码仅仅是把PyQt5安装上,以及安装包中所不包含的文档,但是这些文档最终还是指向了官网,所以感觉文档安装到本机实在是有点鸡肋。最后我决定还是把环境恢复如初,64位的python,再用官网的安装包安装PyQt5,BTW,PyQt5源码卸载方式:nmake uninstall。
其实回过头来看整个过程蛮蛋疼的,不过我还是很享受这个过程的,从中找回了点当年的感觉。