可恶的习惯
时间：2009-02-22 来源：alexe
这两天在写xmpp的客户端，为了让Opener Chat使用。
在Cpan上XMPP的模块一直是一个人写的，http://search.cpan.org/~elmex/.
为了方便，先用PPM查找了一下，竟然没发现XMPP的相关模块。
要不就是XMPP这个模块太不流行了，要不就是这个模块的在Win32下的运行有问题。
因为这个模块也存在很长时间了，所以任务移植应该没太多的问题。也就开始自己手动安装。 安装的是http://search.cpan.org/~elmex/AnyEvent-XMPP-0.4/。 开始的安装到也顺利，可是最后一个需要的模块就是装不上，http://search.cpan.org/~thor/Net-LibIDN-0.11/。 先是Makefile.pl文件无法正确执行，修改了以后可以执行了。生成了Makefile。 然后去http://www.gnu.org/software/libidn/ 下载回Libidn的源代码编译。 然后将编译好的.dll与.lib文件放到Net::Libidn目录下，修改Makefile文件，然后再nmake编译。 出错，提示在Link的时候找不到4个函数。去看Libidn的源代码，发现有这四个函数，只是在win32下编译的时候没有输出，重新修改Libidn代码指定输出，然后再编译。 再次返回，将新编译好的.lib文件放置到目录下，编译Net::Libidn，通过了。然后安装。一切正常。
开始使用 AnyEvent::XMPP模块，然后测试该模块。奇怪的是显示Net::Libidn模块仍然出错。提示无法找到函数。很奇怪，这些函数明明就在编译好的libidn.dll文件中啊。继续检查，终于发现了问题。Net::Libidn模块编译好的动态链接库文件名叫做LibIDN.dll，而这个文件需要去使用libidn编译好的libidn.dll文件，因为win32下不区分大小写，所以他们的名字重复了，windows无法找到libidn.dll文件。当然这个问题在linux下是不存在的。（可恶）。再次回头，重新编译libidn源代码，让其生成的名字改为idn.dll，然后再次去编译安装Net::Libidn，再次去测试AnyEvent::XMPP模块，一切正常。通过了AnyEvent::XMPP的测试。（以上花费时间约3个小时）
至此以为所有的问题都结束了，开始正常使用AnyEvent::XMPP模块写小的测试例子，问题又来了。例子无法正确执行。问题？还是在Net::Libidn模块。这次的问题是Net::Libidn中的函数执行出错。追进Libidn的源代码找到了错误，因为在win32下没有包含某个GNU的外部函数，继续找缺少的.h文件，找缺少的.lib文件，找需要的其他库，继续下载新的库....（以上又花费了2个小时的时间）,原先的错误除去了。但是AnyEvent::XMPP模块的测试例子仍然出错。终于，我要放弃了，结论是：libidn在win32下的移植还有至少10个小时以上的工作要做，还有至少3个其他GNU的库在win32下的问题需要解决。
坐在那里，开始反思，已经工作了接近6个小时。现在知道了为什么AnyEvent::XMPP模块在ppm下没有下载，就是因为这个Net::Libidn无法在win32下移植。忽然，想看看AnyEvent::XMPP中用了多少Net::Libidn中的函数，一查，发现只有两次！！！！！！！！！！！只是两个函数！！！！！！！！！（太可恶）。开始愤怒了。为了两个函数，而使用这个该死的libidn，而导致可移植性大幅下降。问题复杂吗？其实也复杂，那两个函数，花2个小时的时间就应该可以替换掉，而不去使用Net::Libidn。 当然，这个问题不是特例，在cpan上，我经常看见有些很好的模块，动辄就需要5个以上其他模块的支持。而这5个其他模块还需要更其他的模块支持。 我不清楚这样滥用模块的好处，似乎这样分工明确，封装合理，代码简洁。可是，这样却带来的是你的模块的可维护性大大降低。我认为cpan上的开发者，也许需要反省。真的有必要使用那么多的附加模块支持吗？
其实很多小的功能，自己写一个就可以了，这样就避免了使用其他模块。其实，CPAN上的模块那么多，良莠不齐，很容易就能掉进这种模块陷阱。编写代码的时候，还是尽量少引入模块的好啊。
至此，已经花费了10个小时的时间来总结上面的事情。在CPAN上查找时，发现了另一个xmpp的模块http://search.cpan.org/~wilsond/Net-SloppyXMPP-0.04/ 。这个伙计和我一样，也是抱怨AnyEvent::XMPP的可移植性太差，所以就写了这个模块。所以，我想这种可恶的习惯真是需要改一改了。
因为这个模块也存在很长时间了，所以任务移植应该没太多的问题。也就开始自己手动安装。 安装的是http://search.cpan.org/~elmex/AnyEvent-XMPP-0.4/。 开始的安装到也顺利，可是最后一个需要的模块就是装不上，http://search.cpan.org/~thor/Net-LibIDN-0.11/。 先是Makefile.pl文件无法正确执行，修改了以后可以执行了。生成了Makefile。 然后去http://www.gnu.org/software/libidn/ 下载回Libidn的源代码编译。 然后将编译好的.dll与.lib文件放到Net::Libidn目录下，修改Makefile文件，然后再nmake编译。 出错，提示在Link的时候找不到4个函数。去看Libidn的源代码，发现有这四个函数，只是在win32下编译的时候没有输出，重新修改Libidn代码指定输出，然后再编译。 再次返回，将新编译好的.lib文件放置到目录下，编译Net::Libidn，通过了。然后安装。一切正常。
开始使用 AnyEvent::XMPP模块，然后测试该模块。奇怪的是显示Net::Libidn模块仍然出错。提示无法找到函数。很奇怪，这些函数明明就在编译好的libidn.dll文件中啊。继续检查，终于发现了问题。Net::Libidn模块编译好的动态链接库文件名叫做LibIDN.dll，而这个文件需要去使用libidn编译好的libidn.dll文件，因为win32下不区分大小写，所以他们的名字重复了，windows无法找到libidn.dll文件。当然这个问题在linux下是不存在的。（可恶）。再次回头，重新编译libidn源代码，让其生成的名字改为idn.dll，然后再次去编译安装Net::Libidn，再次去测试AnyEvent::XMPP模块，一切正常。通过了AnyEvent::XMPP的测试。（以上花费时间约3个小时）
至此以为所有的问题都结束了，开始正常使用AnyEvent::XMPP模块写小的测试例子，问题又来了。例子无法正确执行。问题？还是在Net::Libidn模块。这次的问题是Net::Libidn中的函数执行出错。追进Libidn的源代码找到了错误，因为在win32下没有包含某个GNU的外部函数，继续找缺少的.h文件，找缺少的.lib文件，找需要的其他库，继续下载新的库....（以上又花费了2个小时的时间）,原先的错误除去了。但是AnyEvent::XMPP模块的测试例子仍然出错。终于，我要放弃了，结论是：libidn在win32下的移植还有至少10个小时以上的工作要做，还有至少3个其他GNU的库在win32下的问题需要解决。
坐在那里，开始反思，已经工作了接近6个小时。现在知道了为什么AnyEvent::XMPP模块在ppm下没有下载，就是因为这个Net::Libidn无法在win32下移植。忽然，想看看AnyEvent::XMPP中用了多少Net::Libidn中的函数，一查，发现只有两次！！！！！！！！！！！只是两个函数！！！！！！！！！（太可恶）。开始愤怒了。为了两个函数，而使用这个该死的libidn，而导致可移植性大幅下降。问题复杂吗？其实也复杂，那两个函数，花2个小时的时间就应该可以替换掉，而不去使用Net::Libidn。 当然，这个问题不是特例，在cpan上，我经常看见有些很好的模块，动辄就需要5个以上其他模块的支持。而这5个其他模块还需要更其他的模块支持。 我不清楚这样滥用模块的好处，似乎这样分工明确，封装合理，代码简洁。可是，这样却带来的是你的模块的可维护性大大降低。我认为cpan上的开发者，也许需要反省。真的有必要使用那么多的附加模块支持吗？
其实很多小的功能，自己写一个就可以了，这样就避免了使用其他模块。其实，CPAN上的模块那么多，良莠不齐，很容易就能掉进这种模块陷阱。编写代码的时候，还是尽量少引入模块的好啊。
至此，已经花费了10个小时的时间来总结上面的事情。在CPAN上查找时，发现了另一个xmpp的模块http://search.cpan.org/~wilsond/Net-SloppyXMPP-0.04/ 。这个伙计和我一样，也是抱怨AnyEvent::XMPP的可移植性太差，所以就写了这个模块。所以，我想这种可恶的习惯真是需要改一改了。
相关阅读 更多 +
排行榜 更多 +
