youtube视频教程
1、 在项目的CMakeLists.txt的开始处加上如下图所示配置(配置中的目录为你需要编译器的目录),平时开发调试的时候,设置SET( CROSS_COMPILE 0 ) 即不启用交叉编译。
2、 交叉编译:首先SET( CROSS_COMPILE 1),然后把项目通过scp传输到linux虚拟机或者服务器上
3、执行 cmake /path/your/project (项目根目录),这一步会生成交叉环境配置的Makefile
4、 在项目根目录,执行 make ,这一步会生成和项目名同名的可执行文件demo中为hello
5、Scp可执行文件到开发版,运行可执行文件。
SET( CROSS_COMPILE 1 )
IF ( CROSS_COMPILE )
SET(
CMAKE_SYSTEM_NAME linux )
SET(
TOOLCHAIN_DIR " /home/sz/project/arm-linux-gnueabihf ")
# specify the cross compiler
SET( CMAKE_C_COMPILER ${ TOOLCHAIN_DIR } /bin/arm-linux-gnueabihf-gcc )
SET(
CMAKE_CXX_COMPILER ${ TOOLCHAIN_DIR } /bin/arm-linux-gnueabihf-g++ )
SET(
GNU_FLAGS " -mfpu=vfp -fPIC ")
SET(
CMAKE_CXX_FLAGS " ${ GNU_FLAGS } ")
SET(
CMAKE_C_FLAGS " ${ GNU_FLAGS } ")
# where is the target environment
SET( CMAKE_FIND_ROOT_PATH ${ TOOLCHAIN_DIR }
${ TOOLCHAIN_DIR } /arm-linux-gnueabihf/include
${ TOOLCHAIN_DIR } /arm-linux-gnueabihf/lib )
# search for programs in the build host directories (notnecessary)
SET( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM
NEVER)
# for libraries and headers in the target directories
SET( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY
ONLY)
SET(
CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY )
ENDIF ( CROSS_COMPILE )
看上去这是一个足够好用的C/C++ IDE,而足够好用的C/C++ IDE并不算多。如果你是一个C/C++程序员,你的IDE选择有什么呢?
Visual Studio是Windows下的当然选择,但是VS的C/C++补全重构功能远远比不上C#的相关功能,而且msvc编译器长期以来支持标准的速度比较慢,使用自有的solution格式也给维护项目增加了很多困惑。
Eclipse CDT和Eclipse本身的缺点很类似。特性很全,但是相对来说bug比较多,比较迟缓。代码提示和搜索功能和JetBrains的产品差一个数量级。
Netbeans的性能和debugger也一直有点问题。非常喜欢不断parse代码。不过支持远程开发和debug是一个非常好的特性。
Qt Creator KDeveloper其实是两个相对不错的选择,但是在智能感知,项目管理、重构、quick fix这些方面始终有些差距。
(我有一段时间没有用过VS/JetBrains以外的ide了,这是我原来实验工具时留下的印象,未必适用于现在的情况。)
如果你满足于使用Windows平台+msvc编译器的话,VS+VA X插件可以提供一个很不错的环境,但是对于使用开源工具链的开发者和Linux开发者来说,并没有太好的选择。vim/emcas的用户多,除了性能和远程开发的方便程度以外,很大程度上是因为这些C/C++ IDE能提供的功能并不比vim+YouCompleteMe提供的特性多。
而就我目前的Beta版使用经验而言,CLion在这些方面做的很不错:
非常好的智能感知功能,自动折叠、高亮、自动补全、类型推断都很好。
Autofix工作的很好。
重构很方便,像inline函数、extract成员函数、常数,pull up/pull down、修改签名这些功能都有。
调试功能很方便,可以自动解析STL容器。
继承了jetbrains系ide的很多优点,像方便的vim插件和keymap调整,滚动条预览,与VCS的紧密集成等等。
跨平台,支持CMake/gcc/clang/mingw/cygwin/gdb。虽然不多,但是其实基本上也够用了。
简洁,没有额外的抽象层,你直接通过控制CMakeLists/CMakeCache来控制项目的编译。这样无需额外学习一遍IDE项目相关的概念,而且省去了VS+CMake时每改一次CMakeLists就要generate一次solution的麻烦。
很快,当然我也没有导入很大很大的项目,不知道结局是什么样。
当然,今天的CLion还有很多缺点,比如说一以贯之的吃内存(随便打开个项目吃掉1G很正常)、比如说还不支持lldb(1.1版本即将支持)、不支持远程开发调试、不支持makefile/autotools项目、没有测试框架支持。最大的问题就是,在处理大项目的时候,CLion的性能能跟得上吗?
不考虑这些因素,CLion是一个很好用的ide。设计合理简洁、核心功能完成的很出色。而像我开篇就说的,能满足这个条件的C/C++ IDE几乎没有。在使用开源工具链的场景下,CLion是第一个让我有理由考虑代替vim的C/C++ IDE.
而这只是一个1.0版本,考虑到JetBrains的一贯水准,CLion的未来值得期待。
欢迎分享,转载请注明来源:夏雨云
评论列表(0条)