Clear

记忆中的闪光,总会蒙尘。
随笔 - 6, 文章 - 0, 评论 - 0, 引用 - 0
数据加载中……

2012年11月15日

让Premake4支持protobuf的protoc生成源文件

最近在使用Premake4进行项目配置生成makefile之类。

比较而言,Premake4比cmake还是感觉简单一点,至少lua语法简单,premake4的配置文件比较简单易读,而cmake的配置文件就比较复杂,而且又是自己定义的一套东西,用起来实在比较烦。

Premake4还有一个比较好用的特性,可以直接用 **/*.cpp 指定项目包含所有目录下的cpp文件,而不用单个指定。这样每次增加一个文件不用老等编译了才想起来忘记了增加文件到配置中。算是给懒人的一个福利吧。

当然,Premake4也有自己的缺陷,目前还不支持自定义规则,所以如果项目中有用到什么自动生成源文件的特性就比较麻烦了,比如这次说到的protobuf要用protoc编译.proto文件生成.pb.cc和.pb.h文件,另外QT也有类似的需求,就我之前某项目中,也使用了tolua++生成过c++的lua接口文件。

但是,Premake4虽然还不支持自定义规则,但是总算有一个prebuildcommands可以用,于是研究了一下,自制了一个.proto文件的"编译规则":

function protobufs(pat)
local list = {}
if type(pat) == "string" then
list[1] = pat;
elseif type(pat) == "table" then
list = pat;
end
local proj = project();
for _,pat in ipairs(list) do
local protofiles = os.matchfiles(pat);
for _,protofile in ipairs(protofiles) do
local basename = path.getbasename(protofile);
local sourcedir = proj.basedir.."/"..path.getdirectory(protofile);
local sourcefile = proj.basedir.."/"..protofile;
local targetdir = "$(OBJDIR)/proto/"..path.getdirectory(protofile);
local targetfile = targetdir.."/"..basename..".pb.cc";
prebuildcommands {
"@mkdir -p "..targetdir,
"@test "..sourcefile.." \\\n"
.."\t\t\t -ot "..targetfile.." || \\\n"
.."\t\t( echo protoc "..protofile.." && \\\n"
.."\t\tprotoc --cpp_out "..targetdir.."\\\n"
.."\t\t\t"..sourcefile.."\\\n"
.."\t\t\t".." -I"..sourcedir.." ) \\\n"
}
files {
path.join(targetdir, basename..".pb.h"),
path.join(targetdir, basename..".pb.cc"),
}
includedirs { targetdir }
end
end
end

使用方法呢,就是把上面的代码保存到protobuf.lua里面,然后在premake4.lua最开始的时候,调用

dofile "protobuf.lua"

然后在项目定义的时候,使用

protobufs { "**/*.proto" }

就可以了。

 

当然,还有一点要注意的,我的系统是mac,但脚本在linux下应该也能同样运行,但是windows下面的话,可能就需要做一点改动了。

posted @ 2012-11-15 22:44 Clear 阅读(1044) | 评论 (0)编辑 收藏

2012年11月11日

MacVim中Pyclewn的配置

换到Mac下面,MacVim自然装上了。

要想调试程序,直接gdb倒也可以,不过就是找代码很费力,这就要看Pyclewn了。

下载,安装,一切似乎都正常。

可是启动pyclewn以后,发现gdb的命令没有输出到buffer?怎么搞?

原来pyclewn用的还是系统自带的gdb,晕,版本好老了。

在.vimrc里面加上

set pyclewn_args='-p ggdb'

指定使用macports的gdb,这就行了。

ps.

MacVim 的snapshot 64版本的balloon显示不出来,不知道怎么回事。

升级到snapshot 65就ok了。

posted @ 2012-11-11 17:38 Clear 阅读(455) | 评论 (0)编辑 收藏

2012年10月28日

GDB在Mac下的调试信息

上次说了GDB的pretty printer,这次来说说调试程序的问题。

在Linux或者Windows下面,写好代码,g++编译,连接,调试,一切很顺畅。

但是在Mac下面,有点小问题。

我们如果是直接编译生成可执行文件:

g++ test.cpp -g -o test

ok,我们用GDB调试,没有问题。
但是如果我们分两步,编译和连接分开的话:

g++ test.cpp -g -c -o test.o
g++ -o test test.o

这次我们gdb test再调试,会发现GDB找不到调试符号信息!

两次生成有什么不同呢?
一次编译生成的test,旁边有一个test.dSYM,而单独连接的test,没有这个。

test.dSYM就是调试符号信息。
要想生成这个东西,也简单,运行dsymutil就可以了: 

dsymutil test

再然后,就可以用GDB顺利调试了。

g++直接生成可执行文件的时候,会帮我们调用一次dsymutil,但是单独连接的时候却不会做这个,这就是造成差别的原因。

posted @ 2012-10-28 23:47 Clear 阅读(558) | 评论 (0)编辑 收藏

2012年9月24日

Mac 下使用GDB的pretty printer

GDB 从7.x版本开始就支持pretty printer

可是一直以来都没有见到这个东西起作用,最近就研究了一下。

我的环境是Mac Mountain Lion + macports,GCC 4.7,GDB 7.5

首先,按照

http://sourceware.org/gdb/wiki/STLSupport

下载checkout STL的pretty printer。

设置好.gdbinit以后,运行告知已经注册,不能重复注册。

$locate printers.py

发现在/opt/local/share/gcc-4.7/gcc-4.7.1/python/libstdcxx/v6已经有一份现成的了。

好吧,我们就使用现有的好了。

写个程序,调试,print,怎么回事?还是不成?

头晕了好久,好在python的源码是可以随便看随便改的,于是在printers.py里面改来改去,调试了半天,发现:

这个printers.py注册了好多stl类型的printer,打印出来有以下这些:

std::__cxx1998::__7::unordered_multiset

std::tr1::unordered_multiset

std::unordered_set

std::tr1::unordered_multimap

std::tr1::__7::weak_ptr

std::__7::bitset

std::__cxx1998::multiset

std::bitset

std::forward_list

std::__7::forward_list

std::__cxx1998::forward_list

std::__7::_Rb_tree_iterator

std::__7::list

std::__debug::unordered_multimap

__gnu_cxx::slist

std::__7::priority_queue

std::__debug::map

std::_List_const_iterator

std::__debug::unordered_map

__gnu_cxx::_Slist_iterator

std::set

std::__cxx1998::__7::_Deque_const_iterator

std::__7::_List_const_iterator

std::__7::multiset

std::shared_ptr

std::__7::queue

std::__cxx1998::_List_iterator

std::tr1::unordered_map

std::__7::vector

std::__debug::queue

std::__norm::_Deque_const_iterator

std::__7::unordered_set

std::__norm::_Deque_iterator

std::__cxx1998::_Deque_iterator

__gnu_cxx::__7::_Slist_iterator

std::__cxx1998::list

std::__cxx1998::__7::list

std::unordered_multimap

std::__cxx1998::unordered_multiset

std::__cxx1998::__7::_List_iterator

std::__7::map

std::__debug::vector

std::tr1::__7::unordered_set

std::__7::basic_string

std::weak_ptr

std::__7::set

std::__7::unordered_multiset

__gnu_cxx::__7::__normal_iterator

std::__cxx1998::__7::vector

std::unordered_map

std::list

std::tr1::__7::unordered_map

std::__7::unordered_multimap

std::vector

std::tr1::unordered_set

std::_List_iterator

std::__7::_Deque_iterator

std::__cxx1998::map

std::__cxx1998::bitset

std::__7::weak_ptr

std::__cxx1998::vector

std::__cxx1998::unordered_set

std::priority_queue

__gnu_cxx::__7::slist

std::__7::_Rb_tree_const_iterator

std::_Deque_const_iterator

std::__7::deque

std::__cxx1998::set

std::__cxx1998::__7::bitset

__gnu_debug::_Safe_iterator

std::tr1::__7::unordered_multimap

__gnu_cxx::__normal_iterator

std::__cxx1998::__7::multiset

std::__cxx1998::__7::unordered_map

std::__debug::unique_ptr

std::__cxx1998::_List_const_iterator

std::_Deque_iterator

std::tr1::__7::unordered_multiset

std::unordered_multiset

std::__cxx1998::__7::unordered_multimap

std::__debug::multiset

std::tr1::weak_ptr

std::__cxx1998::_Deque_const_iterator

std::__cxx1998::unordered_map

std::__7::unique_ptr

std::__debug::list

std::__debug::unordered_multiset

std::__cxx1998::deque

std::_Rb_tree_const_iterator

std::__debug::bitset

std::queue

std::tr1::__7::shared_ptr

std::__debug::unordered_set

std::tr1::shared_ptr

std::__cxx1998::__7::_List_const_iterator

std::__cxx1998::__7::_Deque_iterator

std::__cxx1998::__7::map

std::__7::stack

std::unique_ptr

std::__cxx1998::__7::deque

std::map

std::__7::multimap

std::stack

std::__debug::stack

std::_Rb_tree_iterator

std::multimap

std::__norm::_List_const_iterator

std::__debug::multimap

std::__norm::_List_iterator

std::deque

std::tuple

std::__cxx1998::unordered_multimap

std::basic_string

std::__7::tuple

std::__debug::deque

std::__debug::priority_queue

std::__7::_Deque_const_iterator

std::__7::shared_ptr

std::__cxx1998::__7::multimap

std::__debug::forward_list

std::__7::unordered_map

std::__debug::set

std::__cxx1998::__7::unordered_set

std::__cxx1998::__7::set

std::__7::_List_iterator

std::__cxx1998::multimap

std::__cxx1998::__7::forward_list

std::multiset:

然后,我们的一个简单的string类型,传入到python的lookup里面查找,找不到?

最后发现,string类型传入python以后的basename是basic_string,没有前面的namespace!

于是,在Printer类的add_version函数里面,增加一行

self.add(name, function)

保存,重新打开GDB,调试程序,OK了:

(gdb) p s

$1 = "great"

(gdb) p v

$2 = vector of length 5, capacity 8 = {"a1", "a2", "a2", "a3", "a4"}

posted @ 2012-09-24 23:15 Clear 阅读(1107) | 评论 (0)编辑 收藏

2009年9月27日

CoLinux的网络配置

     摘要: 昨天的说到配置CoLinux在Windows下面启动另一个分区里面的Linux,但是网络配置只是使用了最简单的slirp模式。

CoLinux的网络配置共有3种:

slirp:最简单的模式,CoLinux内可通过Windows系统访问网络,但外部不能直接访问Linux,如果需要访问,需要做端口映射。
tuntap:在Windows中虚拟一块网卡,Linux与Windows通过该网卡通讯,Linux不能直接访问外部网络,必须在Windows上配置路由和NAT,或者简单使用Windows的Internet连接共享ICS。
pcap-bridge:必须有一块连接网络的网卡才能使用,另外需要安装WinPCap软件。该模式将一块实际网卡模拟出另一块网卡并连接到网络,对外部看来,就好像实际上有两台不同机器一样。
ndis-bridge:与pcap-bridge模式一样,不过不使用WinPCap软件接口而是通过Windows的NDIS接口层模拟网卡。  阅读全文

posted @ 2009-09-27 22:29 Clear 阅读(4263) | 评论 (0)编辑 收藏

Windows和Linux双启动,并用在Windows下配置CoLinux启动

     摘要: Windows和Linux都是好东西,配置双启动不难,但是有时候在Windows下面想要临时换到Linux,总是麻烦。

以前都是用VmWare,配置使用实际硬盘,然后再Windows里面进行启动另一个分区里面的Linux然后操作。

不过这样实在是麻烦,而且VmWare占用资源也是在太大,如果配置512内存,就要在系统里面直接占用掉512M内存,即使实际上Linux根本不用那么多。

不过,前段时间发现了CoLinux这个好东西,可以把Linux内核作为Windows的本地进程运行,不错不错。
  阅读全文

posted @ 2009-09-27 01:11 Clear 阅读(1759) | 评论 (0)编辑 收藏