标签：
在vs中开发中，Visual Assist是一个很优秀的插件，我们仍然能够使用它进行代码的分析，但它仅仅能支持vcxprojproject，因而我们选择对vcxproj的project进行扩展，这样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中依据project配置调用就能够轻松搞定。
对于应用程序的调试，VS提供了调试器的引擎。我们扩展此调试器引擎，在调试时使用ssh连接到虚拟机的系统，或者直接连接到目标板。在其上使用gdb载入应用程序进行调试，或者使用gdb连接目标板的gdbserver进行调试。
我们将使用gdb的machine interface，而不是经常使用的交互接口。
驱动的调试尝试使用KGDB，没玩过，玩的时候再说吧。
在调试完毕后将UBOOT、LINUX等project固化成模板，就像这种：
将python控制台、ssh控制台、串口控制台集成到VS中，嘿嘿，够强大了吧~~~~
版权声明：本文博主原创文章。博客，未经同意不得转载。
标签：
原文地址：http://www.cnblogs.com/hrhguanli/p/4852426.html
