I'm working on a Makefile project on Visual Studio, modifying code from my laptop and remotely building on a Linux server which i connect to via ssh.
I configured my project Property pages as such:
General: https://i.stack.imgur.com/3WdP6.png
Debugging: https://i.stack.imgur.com/zI5ua.png
Remote Build > Build command line: cd $(RemoteProjectDir) && echo password |sudo -S make
In the remote project directory i have already every file of the project, Makefile too. When pressing Compile i expect VS to copy the changed code from the local directory, file by file, to the remote one, but the only error i get is this:
Linux.Makefile.Target(108,5): error : Cannot copy \foo\bar\file.cpp remotely to /home/user/projects/MyProject/file.cpp
At line 108 of the file with target extension there is this tag:
<CopySources
Sources ="#(FinalSourcesToCopyRemotely)"
AdditionalSources="#(AdditionalSourcesToCopyRemotely)"
ProjectDir="$(ProjectDir)"
RemoteProjectDir="$(RemoteProjectDir)"
RemoteTarget="$(ResolvedRemoteTarget)"
IntermediateDir="$(IntDir)"
RemoteProjectDirFile="$(RemoteProjectDirFile)"
UpToDateFile="$(CopySourcesUpToDateFile)"
LocalRemoteCopySources="$(LocalRemoteCopySources)">
<Output TaskParameter="ResolvedRemoteProjectDir" PropertyName="_ResolvedRemoteProjectDir" />
</CopySources>
Can this file be the cause of the problem for some reason? Is it good to tinker with a .targets file?
I've already remotely build another project before with same configurations and similar Makefile (adapted for paths and file names) and it worked just fine.
[EDIT]:i've added the command echo password| sudo -S make to interact with the password request prompted by sudo, this worked in the other project and i still get the error
You can't use sudo when debugging . So I'd guess you can't use sudo when building either. The problem is sudo prompts for a password and VSLinux can't handle that. One option is to configure sudo so it doesn't request a password but that's not advised. Can you change your setup so it doesn't require sudo?
Long story short: if you get this error, just create another project with the same exact property as the first one, that'll do.
The problem was probably due to the fact that I changed the property several times before using the right one, which could have created some configuration (-ish) file, unchanged after the modifications.
Related
https://github.com/ninja-build/ninja/releases
I have downloaded the ninja-win.zip folder and extracted it. When I open it, there is a single .exe file in the entire folder. When I double click it a cmd window flashes for a split second. I have also tried running it as administrator, but the same thing happens. What I don't understand is, what am I expected to do with this .exe file?
You must open a terminal (cmd.exe on Windows) and type something like ninja -f /path/to/buld/file. You may also wish to modify the PATH environment variable so that Windows knows where to find the Ninja executable, depending on your setup.
You can simple download ninja.exe file from this Link
https://github.com/ninja-build/ninja/releases
After that you just have to add the path to your ninja.exe file to your windows environment variables and then you can use ninja commands from anywhere in windows.
1. Open cmd in your Project Directory
2. There are guides on the internet on where to save the Ninja.exe so that it'll be callable in Cmd without specifying directory. Either follow them or:
i, Specify Directory when Calling Ninja. Putting "ninja" in Cmd actually calls Ninja.exe and is the same as something like "C:\users\user1\downloads\Ninja". or:
ii, Save Ninja.exe in the same directory as Project.
3. proceed with rest of the command.
Therefore the Final Command would be:
"C:\users\user\downloads\Ninja.exe" -f "D:\Projects\Project1"
I'm running Windows 8.
I installed the MinGW compiler to the default C:\ directory using the GUI installer. I selected to install all the elements available in the Basic Setup package of the MinGW Installation Manager.
After the installation completed, I checked that "C:/MinGW/msys/1.0/etc/fstab" had the one line of C:/MinGW /mingw and an open line beneath it. I also created a shortcut to msys.bat in the Start menu.
Then I rebooted my machine.
I created a folder called "CompileBin" in the C:\ directory, so C:\CompileBin\ and then I placed my test.cpp file inside, so C:\CompileBin\test.cpp
I ran msys.bat and the console opened up. It showed:
MyName,#MyLaptopsName ~
$
I started to navigate to where my test.cpp is:
cd c:\CompileBin\
Now the prompt looked like this:
MyName,#MyLaptopsName ~
$ cd c:\CompileBin\
>
I entered the dir command to look around and got the response:
MyName,#MyLaptopsName ~
$ cd c:\CompileBin\
> dir
sh: cd: c:CompileBindir: No such file or directory
Okay, so I figured maybe the path wasn't set up.
I added PATH to the Environment Variables (because it was NOT originally there) and gave it the value C:\MinGW\bin;
I still get the same error.
Unix tooling requires forward slashes in path names. It is cd c:/CompileBin
I am using CLion (C++ IDE) for editing a ROS package. I was able to open a package by opening the CMakeLists.txt file. But, I get an error,
"FATAL_ERROR "find_package(catkin) failed. catkin was neither found in the workspace nor in the CMAKE_PREFIX_PATH. One reason may be that
no ROS setup.sh was sourced before"
How do I solve this problem? Will I be able to make the project in CLion (If so, how do I) after I make changes to the code or do I have to catkin_make in a separate terminal?
Try this (for Linux):
Open a command line
Run catkin_make on your package.
source your catkin_workspace/devel/setup.bash file e.g. source ~/my_dev_folder/catkin_ws/devel/setup.bash
Start CLion from [CLion install dir]/bin/clion.sh e.g. cd ~/Downloads/clion-1.2.4/bin && ./clion.sh
CLion should then start with knowledge about the packages in your catkin workspace, through the local environment variables set up by the setup.bash file.
To add on to what WillC suggested, you can also modify the desktop entry to start the application from bash instead of manually doing so.
To do this, edit the desktop file located at
~/.local/share/applications/jetbrains-clion.desktop
by modifying the line containing Exec= to
Exec=bash -i -c "/INSTALL_LOCATION/clion-2016.3.2/bin/clion.sh" %f
To add on to what WillC suggested,CLion reload the last cmake compiling result by default.
However, if you failed to find catkin.cmake during the last attempt even though you source the devel/setup.bash and open CLion, you also cannot find catkin.cmake.
You should click File --> Reload Cmake Project and you should get the right result.
I trying to build psql driver but have some unexpected messages.
maxim#maxim-VirtualBox:~/Downloads/distrib/qt-everywhere-opensource-src-5.2.1/qtbase/src/plugins/sqldrivers/psql$ qmake psql.pro
Cannot read
/home/maxim/Downloads/qt-everywhere-opensource-src-5.2.1/qtbase/mkspecs/modules-inst/qt_lib_bootstrap_private.pri:
No such file or directory
...
Cannot read
/home/maxim/Downloads/qt-everywhere-opensource-src-5.2.1/qtbase/mkspecs/modules-inst/qt_lib_xml_private.pri:
No such file or directory
But all of these files exist. What is the problem?
The problem seems to be that you have "modules-inst" as the subfolder name, whereas it is only "modules" without the "-inst" suffix in reality.
See how it works fine on my end:
lpapp ~/Downloads/qt-everywhere-opensource-src-5.2.1/qtbase/src/plugins/sqldrivers/psql $ qmake psql.pro
lpapp ~/Downloads/qt-everywhere-opensource-src-5.2.1/qtbase/src/plugins/sqldrivers/psql $
I found a problem. After install qt-libraries I created new folder 'distrib' and move sources in there. That's why I got this problem.
I should have checked the existence of the directory by cd command.
I am developing an app on Netbeans, while I can run it. I can not debug or reun the test files. When I try to do so, I get:
./build/Debug/GNU-Linux-x86/tests/TestFiles/f1: error while loading shared libraries: libboost_thread.so.1.49.0: cannot open shared object file: No such file or directory
It tried including the library or the specific file with the debugging or testing session, but I continue to get that. Could there be an inconsistency with Netbeans?
Any ideas would be greatly appreciated!
I assume your OS is Linux. It follows from your email that you have access to the copy of the libboost_thread.so.1.49.0 file. Let DIR be directory where this library exists.
If you do not have superuser on this computer, use method A. If you have superuser, use method A or method B.
Method A. Good for non-superuser or for superuser.
Let DIR be directory in which library libboost_thread.so.1.49.0 exists.
I assume you can start NetBeans from shell command line, not from GUI icon.
Quit NetBeans. Execute following command in bash:
export LD_LIBRARY_PATH=DIR:$LD_LIBRARY_PATH
start netbeans from command line
Eventually, you will want to put the export command into your ~/.bashrc file.
Method B. Good only for superuser.
If you have superuser, use one the following methods to place the missing library into /usr/lib or /lib:
(1) install boost from rpm or apt or whatever packaging your linux system has, or
(2) install boost from sources with --prefix=/usr, or
(3) copy the mentioned library to /usr/lib. If you have to use #3, be careful about symlinks. Copy using "cp -a" and copy all files beginning libboost_thread.so*, like
cp -a DIR/libboost_thread.so* /usr/lib