现在xmake在windows下，也已经支持调试运行了，可以在编译完debug版本的程序后，直接进行调试开发。。
我们继续以tbox工程为例：
bash
$ xmake f -m debug
$ xmake r -d demo
上述命令，先配置了debug模式编译，为了启用pdb调试符号文件的生成，然后自动编译后，调试运行demo程序。。
xmake会在配置的时候，自动检测windows上注册表里面的默认调试器，然后加载我们的目标程序并运行。
一般情况下，加载的是vs自带的vsjitdebugger调试器，当然xmake也支持windbg和ollydbg（做逆向的，这个用的比较多哈。。）
我们试着运行demo中的exc
继续阅读 »
xmake默认在编译完程序后，可以通过以下命令运行指定目标程序：
bash
$xmake run [target] [arguments] ...
并且在linux/macosx下面，目前已经支持关联调试器，去直接调试指定目标了，只需要加上-d/--debug参数选项：
bash
$xmake run -d [target] [arguments] ...
默认情况下，xmake在macosx下用的是lldb，在linux下用的是gdb，调试器xmake会在配置的时候去自动检测，如果需要指定调试器路径，可以手动去配置它：
bash
$xmake f --debugger=/usr/bin/gdb
继续阅读 »
本文翻译自liusy182
Jest框架是facebook旗下一款单元测试框架，我个人十分喜欢它，因为它自动mock这一点十分强大。然而，当它遇到问题的时候，就会经常抛出一些模糊的调用栈信息。我在网上搜索尝试找到如何debug Jest测试的方法，却很难找到有用的信息。总之，它仍然还是一个比较新的测试框架。
Jest使用虚拟DOM来运行测试。这一点不同于Karma和Jasmine（它们是利用浏览器来运行测试的）。我觉得这就会给它带来一个很大的缺点：不能使用浏览器上的调试工具来调试Jest的测试。因此，我们需要借助于Node/V8引擎自带的调试器。Node默认的调试器是完全基于命令行形式的，类似于GDB - 虽然我从来就不
继续阅读 »
最近有很多用户反馈xmake在windows上编译体验不是很好，不方便进行调试和开发。。
其实xmake的定位主要还是以直接编译为主，提供跨平台的编译和部署，不依赖第三方IDE工程，不过目前确实在windows的体验还不是很好
尽管我已经优化了在windows下的编译速度，并且提供了xmake run -d xxxx方式，直接加载调试器进行源码调试
但是毕竟整体开发上，没有IDE的支持，对于习惯IDE开发的用户来讲，就不是那么友好了。（虽然我个人觉得用编辑器+printf的方式已经够用了）
因此我下一步计划（原本打算先做好包管理的），打算优先开始支持对Visual Stdio工程文件的生成，到时候会通过project插件的方
继续阅读 »
主页
源码
更新内容
新特性
增加头文件依赖自动检测和增量编译，提高编译速度
在终端中进行颜色高亮提示
添加调试器支持，xmake run -d program ...
改进
增强运行shell的系列接口
更新luajit到v2.0.4版本
改进makefile生成插件，移除对xmake的依赖，并且支持windows/linux/macosx等大部分pc平台
优化多任务编译速度，在windows下编译提升较为明显
Bugs修复
修复安装目录错误问题
修复import根目录错误问题
修复在多版本vs同时存在的情况下，检测vs环境失败问题
继续阅读 »
新特性
在xmake.lua中添加原生shell支持，例如：add_ldflags("$(shell pkg-config --libs sqlite3)")
编译windows目标程序，默认默认启用pdb符号文件
在windows上添加调试器支持（vsjitdebugger, ollydbg, windbg ... ）
添加getenv接口到xmake.lua的全局作用域中
添加生成vstudio工程插件(支持：vs2002 - vs2015)
为option添加set_default接口
改进
增强内建变量的处理
支持字符串类型的选项option设置
Bugs修复
修复在linux下检测ld连接器失败，如果没装g++的话
继续阅读 »