"a bin target must be available for 'cargo run'" - intellij-idea

While building a new Rust "Project from other sources", in Intellij IDEA 2017, I was unable to run the project through its UI.
C:/Users/sjsui/.cargo/bin/cargo.exe run error: a bin target must be
available for cargo run
Process finished with exit code 101
I noticed that no --bin target was provided by my build configuration so I placed the path to the projects target folder; same result.
C:/Users/sjsui/.cargo/bin/cargo.exe run --bin C:\Users\sjsui\exercism\rust\hello-world\target\debug
error: no bin target named C:\Users\sjsui\exercism\rust\hello-world\target\debug
I tried creating a fresh Rust project through the Cargo command line interface, and received this error when running it:
error: could not exec the linker link.exe: The system cannot find the file specified. (os error 2)
note: the msvc targets depend on the msvc linker but link.exe was
not found
note: please ensure that VS 2013 or VS 2015 was installed with the
Visual C++ option
Evidently I must install Visual C++ build tools 2017 and am in the process of doing so. Are these errors related, or different issues?

By default, Cargo will consider the file src/main.rs to be the main binary target for the package. If this file doesn't exist, and there are no other binary targets defined in Cargo.toml, you'll get this error.
According to the documentation, when you create a Rust project in IntelliJ IDEA, you get an option to Use a binary (application) template. This should give you a src/main.rs instead of a src/lib.rs (which is the default root file for a library target). Using Cargo on the command line, you can also create an application package with cargo new hello.
Cargo defaults to --bin to make a binary program. To make a library, we'd pass --lib.
When you use --bin on the cargo run command, the argument refers to one of the [[bin]] sections in Cargo.toml, or files following the pattern src/bin/*.rs (the argument replaces the *) if there are no [[bin]] sections in Cargo.toml. For example, cargo run --bin foo will either compile and run src/bin/foo.rs or the [[bin]] section with name = "foo" in Cargo.toml.

Related

What is the cause for this invalid path issue when trying to run cpp protocol buffer compiler from CMake on Windows 10 and how can I solve it?

I'm trying to build the aasdk project on a Windows 10 computer. To do this, I am attempting to run the following commands in the root of the git repo directory:
mkdir buildDir
cd buildDir
cmake ..\
cmake --build . --config Release
The last command is obviously the one that's failing. I get the following output when I run that command:
-- Selecting Windows SDK version 10.0.18362.0 to target Windows 10.0.19041.
-- Found libusb-1.0:
-- - Includes: C:/libusb-master/x64/Release
-- - Libraries: C:/libusb-master/x64/Release/lib/libusb-1.0.lib
-- Configuring done
-- Generating done
-- Build files have been written to: C:/aasdk-development/buildDir
Microsoft (R) Build Engine version 16.8.3+39993bd9d for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(200
,5): warning MSB8062: Custom build for item "C:\aasdk-development\buildDir\CMakeFiles\b2b8e2a3c1aae1e014a7c3c3f8aadde7\AVCha
nnelData.pb.h.rule" specifies invalid path "C:\aasdk-development\buildDir\aasdk_proto\protobuf::protoc" as an additional dep
endency. This may cause incremental build to work incorrectly. [C:\aasdk-development\buildDir\aasdk_proto\aasdk_proto.vcxpro
j]
...
Running cpp protocol buffer compiler on C:/aasdk-development/aasdk_proto/AVChannelData.proto
The filename, directory name, or volume label syntax is incorrect.
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(238
,5): error MSB8066: Custom build for 'C:\aasdk-development\buildDir\CMakeFiles\b2b8e2a3c1aae1e014a7c3c3f8aadde7\AVChannelDat
a.pb.h.rule;...' exited
with code 123. [C:\aasdk-development\buildDir\aasdk_proto\aasdk_proto.vcxproj]
Where ... is the same message repetead for each *.proto file inside aasdk_proto directory. From what I can tell, it seems it thinks some paths are invalid. What I can't tell, is which paths and in what way are they invalid.
After the first comment, I decided to check where it gets those paths. Below is the content of the CMakeLists.txt for protobuf, found in the aasdk_proto directory:
include(FindProtobuf)
find_package(Protobuf REQUIRED)
include_directories(${PROTOBUF_INCLUDE_DIR})
file(GLOB_RECURSE proto_files ${CMAKE_CURRENT_SOURCE_DIR}/*.proto)
protobuf_generate_cpp(proto_sources proto_headers ${proto_files})
add_library(aasdk_proto SHARED ${proto_headers} ${proto_sources})
target_link_libraries(aasdk_proto ${PROTOBUF_LIBRARIES})
Of interest is the 5th line which enumerates all the *.proto files in the relevant directory before calling protobuf_generate_cpp, the part which I believe to be causing the errors.
Adding message(STATUS ProtoFiles: ${proto_files}) after line 5 to print the paths yielded correct values, atleast to my eyes:
C:/aasdk-development/aasdk_proto/AbsoluteInputEventData.proto;C:/aasdk-development/aasdk_proto/AbsoluteInputEventData.proto;...
I replaced the forward slash with a backslash just for giggles, since that's how Windows likes them, but that didn't work.
I'm a bit late, but for anyone still having this problem, I ran into a similar issue while building CuraEngine, and found the cause. In my case, I had to set the path to protoc.exe with both variables PROTOC and Protobuf_PROTOC_EXECUTABLE. (I had only set PROTOC and CMake didn't throw any errors.)
I imagine the situation with aasdk must be similar. Some variable (probably PROTOBUF_PROTOC_EXECUTABLE?) that tells the location of protoc.exe must be missing.

Building a rust library through CMake and using it as imported library target

I'm restucturing the CMake based build of a cross platform (macOS/Windows, Linux should be added soon) C++ project that has a third party rust library as dependendcy. Until now the rust lib dependency was supplied as precompiled library but I want to make its compilation part of my CMake build.
I got it working on macOS using the CMake makefile exporter by referencing the compiled library as a static imported library target and setting up a custom target with the command to build the rust library through cargo like this
add_library (rustlib STATIC IMPORTED)
add_custom_target (rustlib_cargo
WORKING_DIRECTORY ${CMAKE_CURRENT_LIST_DIR}/Ext/rustlib/c-api
COMMAND cargo rustc --release -- --crate-type staticlib)
# Note: RUSTLIB_OUTPUT is set above refering to the absolute path of the produced platform specific library
set_target_properties (rustlib PROPERTIES IMPORTED_LOCATION ${RUSTLIB_OUTPUT})
add_dependencies (rustlib rustlib_cargo)
On macOS the cargo rustc command is invoked before the targets that link against my rustlib target are built and in case the rust library has been built previously this is detected by cargo and it just skips that compilation steph. But on Windows this fails with the built-in ninja exporter of Microsoft Visual Studio 2019 with an error like this:
ninja : error : '../../../Ext/rustlib/target/release/deps/rustlib.lib', needed by 'SomeTargetLinkingAgainstRustlib', missing and no known rule to make it
If I remove the line set_target_properties (rustlib PROPERTIES IMPORTED_LOCATION ${RUSTLIB_OUTPUT}) the build starts correctly, the rust build gets triggered, but as expected I end up with a linker error as the library to link against is not found. So is there any way to refer to a file that is not existent at configuration time but is guranteed to be created during compilation?

Problems with CPack building multiple packages at once

I'm facing problems using the packaging with CPack and CMake 3.7.2.
I try to build three different packages, MSI (via WIX), IFW, and ZIP.
According to the documentation I set the following variables in my CMakeLists.txt (and a few more which are required):
set(CPACK_WIX_ROOT "C:/Temp/WiX-3.10/binaries")
set(QTIFWDIR "${GLOBAL}/Qt/Tools/QtInstallerFramework/2.0/bin")
set(CPACK_GENERATOR "WIX;IFW;ZIP")
I'm including CPack at the last possible position before any components are defined.
<all variables have been defined before this point>
include(CPack)
include(CPackWIX)
include(CPackIFW)
cpack_add_component(AppBinaries DISPLAY_NAME "MyAppBinaries" DESCRIPTION "My Application Binaries")
cpack_ifw_configure_component(AppBinaries VERSION ${CPACK_PACKAGE_VERSION} SCRIPT "${CMAKE_SOURCE_DIR}/cpack/installscript.qs")
cpack_add_component(AppDocs DISPLAY_NAME "MyAppDocs" DESCRIPTION "My Application Docs")
cpack_add_component(AppData DISPLAY_NAME "MyAppData" DESCRIPTION "My Application Data")
After creating the build dir and running from there
cmake -G "Visual Studio 14 2015 Win64" ..\TestProject
the files CMakeCache.txt, CPackConfig.cmake, CPackSourceConfig.cmake, and CPackProperties.cmake are generated.
When running cpack -C Release to build all three installers at once, the first one (WIX) is built, but the second one (QtIFW) fails with the messages
CPack Error: Cannot find QtIFW compiler "binarycreator": likely it is
not installed, or not in your PATH CPack Error: Cannot initialize the
generator IFW
I inspected the CMakeCache.txt file but found the following entries properly defined:
//QtIFW binarycreator command line client
CPACK_IFW_BINARYCREATOR_EXECUTABLE:FILEPATH=N:/Global/Qt/Tools/QtInstallerFramework/2.0/bin/binarycreator.exe
//QtIFW devtool command line client
CPACK_IFW_DEVTOOL_EXECUTABLE:FILEPATH=N:/Global/Qt/Tools/QtInstallerFramework/2.0/bin/devtool.exe
//QtIFW installer executable base
CPACK_IFW_INSTALLERBASE_EXECUTABLE:FILEPATH=N:/Global/Qt/Tools/QtInstallerFramework/2.0/bin/installerbase.exe
//QtIFW repogen command line client
CPACK_IFW_REPOGEN_EXECUTABLE:FILEPATH=N:/Global/Qt/Tools/QtInstallerFramework/2.0/bin/repogen.exe
//Enable to build 7-Zip source packages
CPACK_SOURCE_7Z:BOOL=ON
//Enable to build ZIP source packages
CPACK_SOURCE_ZIP:BOOL=ON
//Path to a program.
CPACK_WIX_CANDLE_EXECUTABLE:FILEPATH=C:/Temp/WiX-3.10/binaries/candle.exe
//Path to a program.
CPACK_WIX_LIGHT_EXECUTABLE:FILEPATH=C:/Temp/WiX-3.10/binaries/light.exe
But when I checked the CPack\*Config.cmake files none of the entries above are referenced. After running the cmake -G "Visual Studio 14 2015 Win64" ..\TestProject a second time everything is fine; all those entries are referenced in CPack\*Config.cmake files and all three installers can be built.
So I really get stuck at this point.
Any ideas what could be the issue and how to avoid it?
I finally figured out what didn't work as expected. The setting of the QTIFWDIR variable is not saved to the CPack*Config.cmake files, but the CMAKE_WIX_ROOT variable is. Those variables seem to be evaluated at runtime by CPack. Therefore the WIX build run successfully but the IFW build complained about a the missing binarycreator. Adding the variable with its current setting made everything run as expected.
Follow up:
According to the maintainer QTIFWDIR should be rather an environment variable than a CMake variable. And CPACK_WIX_ROOT is considered to be an internal CPack variable. You need to install WIX (and set the WIX environment variable manually, if it hasn't already been done by the installation).

Can the object file name be changed from .obj during cmake compiler testing?

Ultimately, I'm trying to build Apache QPID to run in the HPE NonStop OSS environment (a Posix-like environment on the NonStop system). The latest version of QPID uses cmake to build so I first need to get cmake to work for that environment. My earlier attempts tried to build in OSS directly (I needed to build cmake first before trying to build QPID), but I ran into many problems there. So lately I'm trying to build in Windows using a set of cross-development tools (compilers etc.) for NonStop. I've downloaded a Windows version of cmake 2.8 (suggested by the QPID build instructions) and am trying to use that with the X-dev tools to build QPID for OSS.
One big issue I've run into has to do with how cmake does things to test compilers and so forth early on. It will invoke the compiler to create an intermediate object file from C (and/or C++) source file and after that it will invoke the compiler to link an object file from the intermediate file. It seems that cmake prefers to add .obj to file names to create the intermediate object file name. This will work OK with my cross-compiler when creating the file (the name passed with -o to the compiler) but it will not work when passing this name for link purposes. Here is a short bit of the output per the CMakeError.log file (from trying build an OSS version of cmake 2.8 itself):
Determining if the C compiler works failed with the following output:
Change Dir: C:/Source/cmake-2.8.0/bld/CMakeFiles/CMakeTmp
Run Build Command:C:/cygwin/bin/make.exe "cmTryCompileExec/fast"
/usr/bin/make -f CMakeFiles/cmTryCompileExec.dir/build.make CMakeFiles/cmTryCompileExec.dir/build
make[1]: Entering directory '/cygdrive/c/Source/cmake-2.8.0/bld/CMakeFiles/CMakeTmp'
"C:/Program Files (x86)/CMake 2.8/bin/cmake.exe" -E cmake_progress_report C:/Source/cmake-2.8.0/bld/CMakeFiles/CMakeTmp/CMakeFiles 1
Building C object CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.obj
/cygdrive/c/NonStop/tndm_cmplrs-j20/usr/bin/c89.exe -o CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.obj -c C:/Source/cmake-2.8.0/bld/CMakeFiles/CMakeTmp/testCCompiler.c
Linking C executable cmTryCompileExec
/cygdrive/c/NonStop/tndm_cmplrs-j20/usr/bin/c89.exe "CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.obj" -o cmTryCompileExec
c89.exe: error: Invalid input file extension"CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.obj".
The cross-compiler fails because it requires intermediate object files to use .o for the extension, in order to determine they are intermediate object files. There is no way to get the c89 compiler to recognize testCCompiler.c.obj as a file type it knows what to do with.
So I've been searching (trying to find a local expert, but no one in my organization knows cmake; also numerous Google searches but could not find an answer) to see if there is any way to get cmake to change the name of the output file it uses for these type of compiles and tests. I've found info and then set CMAKE_C_OUTPUT_EXTENSION in a toolchain file:
SET(CMAKE_C_OUTPUT_EXTENSION ".o")
but that has made no difference.
If I can find a way to get cmake to create object files with names like testCCompiler.c.o instead of testCCompiler.c.obj, then the c89 cross-compiler would work.
Is it possible to do this?
UPDATE: I've managed to figure out that setting CMAKE_C_OUTPUT_EXTENSION in the toolchain file doesn't help. This gets overwritten in the CMakeCInformation.cmake (depending on whether UNIX is set or not). I also tracked down that UNIX gets set to true in Platform/UnixPaths.cmake, which gets INCLUDEd by various Platform files. So I've created a Modules/Platform/OSS.cmake file which includes it to takes care of that. I'll probably need/want to add other settings there later as I determine more flags for compilers etc that should be set to specific values for the OSS environment.

error LNK1104 cannot open file 'gtest.lib'

I was trying to install a neural networks toolbox called CarlSim using visual studio 2012, in which they use gtest in their code. I try to install gtest by downloading it online and build using gtest.sln file. It gives me two warnings. I guess these two warnings are the reason for this error. But I don't know how to solve this. The gtest seems only can build gtestd.lib.
Below is the error during install of the neural network toolbox
Error 2 error LNK1104: cannot open file 'gtest.lib' C:\Users\Dukerama\Desktop\CarlSim\carlsim\test\LINK carlsim_tests
Below are the warnings of the gest.
1>------ Rebuild All started: Project: gtest, Configuration: Debug Win32 ------
1> gtest-all.cc
1>C:\Program Files(x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppBuild.targets(1299,5): warning MSB8012: TargetPath(C:\Users\Dukerama\Desktop\gtest\gtest- 1.6.0\msvc\gtest/Debug\gtest.lib) does not match the Library's OutputFile property value (C:\Users\Dukerama\Desktop\gtest\gtest-1.6.0\msvc\gtest\Debug\gtestd.lib). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Lib.OutputFile).
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppBuild.targets(1301,5): warning MSB8012: TargetName(gtest) does not match the Library's OutputFile property value (gtestd). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Lib.OutputFile).
1> gtest.vcxproj -> C:\Users\Dukerama\Desktop\gtest\gtest-1.6.0\msvc\gtest/Debug\gtest.lib
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========
Output from build command in VS you have posted suggests that there are inconsistencies between certain values in VS project properties for gtest (located in 'Configuration Properties -> General' and in 'Configuration Properties -> Librarian -> General'). However, output also suggests that the gtest library is built at location:
C:\Users\Dukerama\Desktop\gtest\gtest-1.6.0\msvc\gtest/Debug\gtest.lib
You should take this file and place it in directory where CarlSim toolbox expects to find the gtest library. You can find this out in the VS project properties for CarlSim ('Configuration Properties -> Linker -> General -> AdditionalLibraryDirectories').
P.S.
Make sure that both gtest and CarlSim link to the same runtime library, or you'll get more linker errors. You can inspect the runtime library in their VS project properties at 'Configuration Properties -> C/C++ -> Code Generation -> Runtime Library'.
I had the same problem.
Unfortunately, the proposed solution didn't help me.
In my case, the build worked properly on my PC, but it gave the error on a collegue's PC.
We solved it moving the project in a new location with a shorter path.