在vs中开发中,Visual Assist是一个非常优秀的插件,我们仍然可以使用它进行代码的分析,但它只能支持vcxproj工程,因而我们选择对vcxproj的工程进行扩展,这样VisualAssist就可以正常使用了。
此外,VS的智能感知不支持GCC的一些扩展,在做代码分析的时候可能出错,我们采用强制包含头文件的方式解决一部分问题:
注意,这个文件的目的是让VS能够进行代码的分析,而不是让VS具有编译这些代码的能力!!!
这个头文件类似于这样的:
#pragmaonce
// 本文件的作用仅在于使VS能够解决语法错误,而不在于让程序正确运行!!!
#define__attribute__(x)
#define__signed__ signed
#defineinline__inline
#defineBITS_PER_LONG 4
#define_TIME_T
#define__inline__
#define__u64int
…….
很早之前,想通过移植GCC到cywin下面进行编译,最后放弃了。
其中一个原因是cywin的速度较慢,虽然是windows下的本地应用,但它的编译速度比虚拟机里运行gcc还是要慢不少。究其原因,主要是cywin在模拟fork操作时使用的技术影响了其速度(见其它文章的分析)。
放弃cywin的另一个原因是嵌入式Linux平台提供的编译器都是基于Linux的,很难把这些编译器做移植。
因而我们采用远程编译的方法,当VS进行编译操作的时候,使用SSH登录到虚拟机的Linux系统中进行编译,再分析编译过程中产生的信息,将之转换为vs能够识别的信息,这样VS就可以在IDE中正确定位错误发生的文件!
在这种方式中,Make或者gcc生成的错误信息由于编译方式的不同产生的错误信息是有差异的,为了处理这种差异,我们将这个过程用python来完成。这样在不同的项目中只需要对python脚本做少量修改就可以了,这个脚本完全可以做为项目的一部分。
这种方式获得的另一个好处是大大降低VS扩展的代码,从而保证了它不会影响到VS的稳定性。
VS2012使用MSBUILD进行生成,它允许在一个项目改写自己的生成过程,将默认行为指向自定义的扩展,这也是我们要采用的方式。
对比VC和GCC的编译参数可以发现有很多参数是相同的,如宏定义、附加目录等等,这部分可以直接使用,除此之外还有一些特定的参数,我们通过为VS添加新的平台和属性页的方式进行支持。
这样我们可以通过VC的项目属性来配置GCC的特定参数。
对于Linux内核的配置,实际上是由scripts/kconfig/mconf或者scripts/kconfig/qconf程序来完成的,其实现过程是读取Kconfig文件生成菜单,再根据用户选择生成.config文件,我们将之简单修改完全可以在windows下进行配置:
在VS中根据工程配置调用就可以轻松搞定。
对于应用程序的调试,VS提供了调试器的引擎,我们扩展此调试器引擎,在调试时使用ssh连接到虚拟机的系统,或者直接连接到目标板,在其上使用gdb加载应用程序进行调试,或者使用gdb连接目标板的gdbserver进行调试。
我们将使用gdb的machine interface,而不是常用的交互接口。
驱动的调试尝试使用KGDB,没玩过,玩的时候再说吧。
在调试完成后将UBOOT、LINUX等工程固化成模板,就像这样的:
将python控制台、ssh控制台、串口控制台集成到VS中,嘿嘿,够强大了吧~~~~