在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中，嘿嘿，够强大了吧~~~~
原文地址：http://blog.csdn.net/lights_joy/article/details/41216993
