I am now reading a ROS package built on catkin_tools. It is complicated so I need to import this project into an IDE (like Clion, QT Creator, etc). Although the official doc of catkin-tools says you can't rely on CMake's IDE integration (http://catkin-tools.readthedocs.io/en/latest/migration.html?highlight=IDE), I still have some hope on this. So does anyone has such experience?
PS: I also found the author of ros_qtc_plugin claimed he has added the function of catkin_tools, but I still could not find how to do this.
Note: The following solution works for catkin build, but not for catkin_make. If you are using catkin_make, please visit:
https://stackoverflow.com/a/35143865/2422098
https://www.jetbrains.com/help/clion/2020.2/ros-setup-tutorial.html#set-build-paths
CLion configuration for catkin_tools workspaces (catkin build)
Please excuse me for digging up an old question, but I just came across this problem and found a solution for CLion and catkin_tools (i.e., when building with catkin build).
I tested the proposed solution on 20.04 with ROS Noetic and CLion 2020.2.4.
According to the docs, catkin_tools uses an individual devel workspace path for each ROS package:
https://catkin-tools.readthedocs.io/en/latest/advanced/linked_develspace.html
The devel prefix path for a package:
-DCATKIN_DEVEL_PREFIX:PATH=/home/<user-name>/catkin_ws/devel/.private/<package-name>
The build directory for a package:
/home/<user-name>/catkin_ws/build/<package-name>
To open and edit a ROS package in CLion, please follow these steps:
run catkin build in the workspace
Source /opt/ros/$ROS_DISTRO/setup.bash and your workspace setup.bash in the devel folder
After that, start CLion from the command line, so that it inherits the environment variables
In CLion's Open Project wizard, navigate to the ROS package, and select the
CMakeLists.txt. When prompted, click Open as Project
Open the Settings Window (usually Ctrl+Alt+S)
Navigate to "Build, Execution, Deployment" > "CMake"
Under "CMake options", specify the devel prefix as mentioned above, and under "Build directory", specifiy the build directory as mentioned above:
Explanation:
When configured in the aforementioned way, the generated CMake files and build files that catkin build creates are reused by CLion.
By default, when not configuring it to reuse the build files, CLion would create its own cmake-build-debug/ generation directory. I experienced the following issues with this dedicated generation/build directory:
Problems when CLion is not configured as described in the above steps:
The nodes/libraries are built twice (CLion, catkin build), which increase development time.
Libraries are built twice, but the CLion build links with ~/catkin_ws/devel .so-files and not the cmake-build-debug/ .so-files. This is confusing when working on a ROS package with at least one library, since building the library in CLion is a dead-end and the .so-output is never used.
Since executables are built twice, rosrun has an ambiguity problem as it finds two executables for the specified node. An executable selection prompt appears each time rosrun is used.
I have had success using Eclipse to work with ROS in the past. See: http://wiki.ros.org/IDEs#Creating_the_Eclipse_project_files for setup details.
If you want something that works right out of the box, you can try a free IDE called RoboWare that is specifically built for and integrates with ROS very well.
http://www.roboware.me/#/home
Related
I'm trying to run a piece of software I built in MSYS2 MINGW32 shell. The software is 32bits (don't have time to port it to 64bits) and there is one statically linked executable. Here is how I setup the build environment:
Installed a fresh copy of MSYS2;
$ pacman -Syu
Installed the following packages: git mingw-w64-i686-gcc mingw-w64-i686-cmake mingw-w64-i686-SDL mingw-w64-i686-SDL_mixer mingw-w64-i686-zlib mingw-w64-i686-libpng mingw-w64-i686-make
Git checkout the repo
Run the build in CMake
Build runs fine and the exe is generated.
Now the problem starts: the executable can't run and displays an error message about missing DLLs. I copied the missing DLLs to the same folder of the executable, and them another error message pops up complaining about error 0xC000007B, which I tracked down to be missing dependencies. After a while I figured out that the problem was that some of the DLLs is missing a dependency itself. Copied this last dependency to the folder.
Now, the big question: I can run the exe perfectly fine in the MINGW32 shell but I can't run it neither in cmd.exe nor by double-clicking in Windows Explorer and this is a problem (I can't ship a software this way). Is there any way to produce a binary that is able to run from explorer and from cmd.exe? What is the cause of this problem? Can it be mitigated?
I solved my problem!
After a lot of research, I realized that nothing was wrong with my MSYS2 build/setup/dependencies. The real problem was that CMake hide one parameter for the linker: -mwindows. Actually, the CMake find_package routine from one of the libraries I'm using (SDL) added this parameter to the linker command line parameters.
Adding a -mconsole to the linker parameters (using add_link_options("-mconsole")) solved the problem. The CLI now works as expected.
Thank you all for your help.
I have CMake working perfectly fine with Visual Studio 2015. I wanted to try VS Code with C++ and CMake extensions, but when I try to call the build command (configured to F7 by default with the CMake extension for VSCode), I only get the message:
command 'cmake.build' not found
Is it trying to tell me it can't find CMake ? Because Cmake is installed and working so... I also tried changing in the settings to the full path to cmake with no success. I installed both CMake and CMake Tools from Extensions. Also the toolbar for CMake doesn't appear on the blue VSCode toolbar as shown in CMake Tools extension doc.
Edit:
The author of that extension believes they've resolved this issue in the latest version 0.9.7.
https://github.com/vector-of-bool/vscode-cmake-tools/issues/157#issuecomment-307005140
So, I've just pushed 0.9.7:
No more dependency on twxs.cmake, so that shouldn't be causing any
issues anymore
#ytimenkov fixed some version parsing code that was
lying about what version of CMake was installed. Should fix issues
people are seeing with pre-3.7 versions.
#ytimenkov added better
errors when initialization failed. This should help create future
tickets!
As such, I'm going to close this issue and ask that anyone
with any further issues open a new ticket using the new error messages
that appear during a failed initialization.
I too had this issue and was given a solution here in my ticket.
For some people, one of their dependencies isn't getting installed correctly on our system. So you need to install another additional extension to get it to work.
It's called "CMake" or "twxs.cmake" (actual package name) and can be found here: https://marketplace.visualstudio.com/items?itemName=twxs.cmake
If it still isn't working, some have reported that they needed to uninstall both extensions then reinstall them both to get it to work--making sure to restart VSCode.
try this:
create a new copy of "mingw32-make.exe".
rename the copy to "make.exe".
restart your vscode.
An existing Java project uses makefiles (which in turn uses ANT).
I want to work on this project using IntelliJ IDEA. However, no IntelliJ specific files, e.g. project files, should be checked in to version control.
How can I configure the project so that:
Makefiles can be run from inside IntelliJ IDEA.
Change Build > Make Project so that it either does nothing or runs some make target (in a makefile). I do not want to the standard behavior of compiling into ./bin since this potentially can conflict with the makefiles.
For Windows users
So far, the guidance provided by Dannil Maslov ( see intelliJ IDEA thread here ) worked for me.
Install GnuWin32 (Make for Windows).
Install the IDEA Makefile plugin.
Go to settings and specify the path to make executable under: File | Settings | Build, Execution, Deployment | Make | Path to Make executable (by default: C:\Program Files (x86)\GnuWin32\bin\make.exe). Check "Use Cygwin" if necessary.
If you have used chocolatey ( choco install make ) , change the path in step 3 accordingly.
You should be up and running.
A compilation database feature became available in 2018.
The help page says:
Make-based projects:
The compiledb-generator tool creates compilation databases for make-based build systems.
Bear and intercept-build tools:
Bear and intercept-build from scan-build are the tools to help you get a compilation database by intercepting compiler calls during the build.
(Bear and intercept-build work on Linux, by injecting themselves into LD_LIBRARY_PATH)
Our project uses CMake to configure our code. We use Ninja along with a distributed build system. A number of people on our team use Eclipse CDT. We run CMake with the "Eclipse CDT4 - Ninja" generator and the result is generally pretty good.
The issues is that any time a CMake file is changed and you ask Eclipse to build the code it regenerate the eclipse project file overwriting any manual changes you've made to the project.
For example the default build command that it provides the eclipse project is /usr/bin/ninja when in fact I want to take advantage of our distributed build system and set the build command to /usr/bin/ninja -j16. It would be nice if I could have the project file that CMake generates automatically include this setting change.
The other setting I am most interested in preserving is the C/C++ Project Paths->Source. As a general rule we place our CMake build directory as a sibling to the main project directory i.e. ./project ./build. We want to include some files in the build directory in the Eclipse index to make code completion and other tools work better. The default project doesn't include the build directory in source path and thus it does not get indexed.
Is there some way to remedy these issues?
I found a solution to build command issue.
When you run cmake to generate the eclipse project include the additional argument:-DCMAKE_ECLIPSE_NINJA_ARGUMENTS=-j100. I haven't confirmed but I believe a similar command is required for eclipse make projects -DCMAKE_ECLIPSE_MAKE_ARGUMENTS=-j100.
Unfortunately this feature is poorly documented and I have not found a solution to my other issue.
When building the project from command line using mvn clean install everything builds without any issues.
When running some tests that use precompiled C libraries from IntelliJ, tests fail with java.lang.UnsatisfiedLinkError
I may be completely off here, but does IntelliJ not see the .so file? Is so, how can it be added please?
Shared library fails to load with UnsatisfiedLinkError if:
it's not in the working directory configured in the test run configuration.
it's not in PATH environment (on Mac Terminal and GUI apps have different environment, see this answer). Run IDEA from the Terminal open -a /Applications/IntelliJ\ IDEA\ 12.app/ to make environment the same.
it's not in the location specified using -Djava.library.path VM option.
.so depends on some other library that is not found for any of the 1-3 reasons (or the dependency of that dependency is not found, etc).