Building and debugging cmake app

[kbzowski]

Hi, what is the correct solution to import existing cmake based application and work with it?
Right now I am importing source, and after that run cmake to create MakeFile. Is it correct? Will I need import project again when I will modify CMakeLists.txt (by adding new files)?
Using that method I cannot run out-of-source build (MakeFile is located in different directory than source files).
I am working in environment without any directories shared between Linux and Windows platforms.

[ket]

Do not copy the source files to a new location from the Makefile location, the source tree shown in Visual Studio projects is only for the convenience of sorting and opening the files and does not refer to the physical location. Adding new files to the project only adds the files automatically to the Makefile if you are using the VisualGDB generated Makefile. You do not need to import the project again if you add files to CMakeLists.txt, importing is just meant for the convenience of importing the entire source at the beginning of a project. Putting it all together, import the source and Makefile, CMakeLists.txt when making the project, make sure the project builds, when adding files later on, make sure you also add them in the Makefile.

Better handling of CMake projects is currently being considered as a feature for the next VisualGDB version. If you have any feature suggestions, let us know.

[Anonymous]

In current version CMake-based build runs as expected, but out-of-source cmake builds lead to VisualGDB “warning VGDB001: Inconsistent depth reported by GNU Make”. It would be great if VisualGDB will suppress such warnings if case of CMake projects.

[support]

Could you paste a typical build log showing the problem here? Looks like cmake uses a different format for “entering directory”/”leaving directory” messages and this confuses VisualGDB.

[Anonymous]

Sorry for the late reply. I’ve just checked this topic again.
I’ve root-caused the warning source. It have nothing to do with cmake, but rather make option -j8, which parallels build (and speedup it appropriately 🙂 ) causes warning. Seems in current version VisualGDB expects single-thread build process.

36>  VisualGDB: Attempting inline build...

36>  VisualGDB remote project path: /home/user/projectname/src

36>  No file changes detected. If you believe it's a mistake, please clean the project and build it again.

36>  make -j8 -C __cmake/intel64.make.debug

36>  make: Entering directory `/home/user/projectname/src/__cmake/intel64.make.debug'

36>  /usr/bin/cmake -H/home/user/projectname/src -B/home/user/projectname/src/__cmake/intel64.make.debug --check-build-system CMakeFiles/Makefile.cmake 0

36>  /usr/bin/cmake -E cmake_progress_start /home/user/projectname/src/__cmake/intel64.make.debug/CMakeFiles /home/user/projectname/src/__cmake/intel64.make.debug/CMakeFiles/progress.marks

36>  make -f CMakeFiles/Makefile2 all

36>  make[1]: Entering directory `/home/user/projectname/src/__cmake/intel64.make.debug'

36>  make -f samples/sample_common/CMakeFiles/sample_common_type1.dir/build.make samples/sample_common/CMakeFiles/sample_common_type1.dir/depend

36>  make -f samples/sample_common/CMakeFiles/sample_common_type2.dir/build.make samples/sample_common/CMakeFiles/sample_common_type2.dir/depend

36>  make -f samples/sample_utilities/some_plugin/CMakeFiles/some_plugin.dir/build.make samples/sample_utilities/some_plugin/CMakeFiles/some_plugin.dir/depend

36>  make -f _studio/prj_lib/CMakeFiles/prj_lib_merged.dir/build.make _studio/prj_lib/CMakeFiles/prj_lib_merged.dir/depend

36>  make -f _studio/prj_lib/CMakeFiles/prj_lib_merged_hw.dir/build.make _studio/prj_lib/CMakeFiles/prj_lib_merged_hw.dir/depend

36>  make -f _studio/prj_lib/CMakeFiles/prj_lib_merged_sw.dir/build.make _studio/prj_lib/CMakeFiles/prj_lib_merged_sw.dir/depend

36>  make[2]: Entering directory `/home/user/projectname/src/__cmake/intel64.make.debug'

36>  cd /home/user/projectname/src/__cmake/intel64.make.debug && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /home/user/projectname/src /home/user/projectname/src/samples/sample_utilities/some_plugin /home/user/projectname/src/__cmake/intel64.make.debug /home/user/projectname/src/__cmake/intel64.make.debug/samples/sample_utilities/some_plugin /home/user/projectname/src/__cmake/intel64.make.debug/samples/sample_utilities/some_plugin/CMakeFiles/some_plugin.dir/DependInfo.cmake --color=

36>EXEC : warning VGDB001: Inconsistent depth reported by GNU Make

36>  make[2]: Entering directory `/home/user/projectname/src/__cmake/intel64.make.debug'

36>  cd /home/user/projectname/src/__cmake/intel64.make.debug && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /home/user/projectname/src /home/user/projectname/src/samples/sample_common /home/user/projectname/src/__cmake/intel64.make.debug /home/user/projectname/src/__cmake/intel64.make.debug/samples/sample_common /home/user/projectname/src/__cmake/intel64.make.debug/samples/sample_common/CMakeFiles/sample_common_type1.dir/DependInfo.cmake --color=

36>EXEC : warning VGDB001: Inconsistent depth reported by GNU Make

36>  make[2]: Entering directory `/home/user/projectname/src/__cmake/intel64.make.debug'

36>  cd /home/user/projectname/src/__cmake/intel64.make.debug && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /home/user/projectname/src /home/user/projectname/src/samples/sample_common /home/user/projectname/src/__cmake/intel64.make.debug /home/user/projectname/src/__cmake/intel64.make.debug/samples/sample_common /home/user/projectname/src/__cmake/intel64.make.debug/samples/sample_common/CMakeFiles/sample_common_type2.dir/DependInfo.cmake --color=

36>EXEC : warning VGDB001: Inconsistent depth reported by GNU Make

36>  make[2]: Entering directory `/home/user/projectname/src/__cmake/intel64.make.debug'

36>  cd /home/user/projectname/src/__cmake/intel64.make.debug && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /home/user/projectname/src /home/user/projectname/src/_studio/prj_lib /home/user/projectname/src/__cmake/intel64.make.debug /home/user/projectname/src/__cmake/intel64.make.debug/_studio/prj_lib /home/user/projectname/src/__cmake/intel64.make.debug/_studio/prj_lib/CMakeFiles/prj_lib_merged.dir/DependInfo.cmake --color=

36>EXEC : warning VGDB001: Inconsistent depth reported by GNU Make

36>  make[2]: Leaving directory `/home/user/projectname/src/__cmake/intel64.make.debug'

36>  make -f samples/sample_utilities/some_plugin/CMakeFiles/some_plugin.dir/build.make samples/sample_utilities/some_plugin/CMakeFiles/some_plugin.dir/build

36>EXEC : warning VGDB001: Inconsistent depth reported by GNU Make

36>  make[2]: Leaving directory `/home/user/projectname/src/__cmake/intel64.make.debug'

36>  make -f samples/sample_common/CMakeFiles/sample_common_type2.dir/build.make samples/sample_common/CMakeFiles/sample_common_type2.dir/build

36>EXEC : warning VGDB001: Inconsistent depth reported by GNU Make

36>  make[2]: Leaving directory `/home/user/projectname/src/__cmake/intel64.make.debug'

36>  make[2]: Entering directory `/home/user/projectname/src/__cmake/intel64.make.debug'

36>  make[2]: Nothing to be done for `samples/sample_utilities/some_plugin/CMakeFiles/some_plugin.dir/build'.

36>  make[2]: Leaving directory `/home/user/projectname/src/__cmake/intel64.make.debug'

[support]

Hi,

Yes, VisualGDB expects the single-threaded output as it’s the only way to detect the full path of files (so that Visual Studio can show them) when GCC reports the relative path. If this is not a problem for you, you can safely ignore those warnings.

[Author]

Posts