Cannot build .so from project context menu – "No rule to make target"

[wilstark]

I have a small test project (1 C# project, 1 C++ library, 1 C++ executable).  Running VisualGDB 5.4r7 build 3207. VS 2017. VisualGDB is ‘advanced CMake integration’.  Underlying build system ‘Auto’.  Linux build machine is a recent UbuntuMate virtual machine.

I can build the entire solution OK using VS ‘Build Solution’.

But if I clean my ‘Shared’ .so project (rt. click context menu of .so target, choose ‘clean target’, then same rt. click, choose ‘build target’), I get:

—— Build started: Project: LinuxTargets, Configuration: Debug VisualGDB ——
VisualGDB: c:\tf\ws1\cmaketest => /tmp/VisualGDB/dwstark/cmaketest: 422 files are up-to-date.
VisualGDB: Run “make libShared.so” in directory “/tmp/VisualGDB/dwstark/cmaketest/VisualGDB/Debug/libShared” on dwstark@wilvm2 (SSH)
make: *** No rule to make target ‘libShared.so’. Stop.
————————————————————-
Command exited with code 2
Executable: make
Arguments: libShared.so
Directory: /tmp/VisualGDB/dwstark/cmaketest/VisualGDB/Debug/libShared
VisualGDB: Error: Command-line action failed
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

I’d like to be able to build individual targets with the context menu rather than building only with ‘build solution’.

If I now choose build solution, the output is:

1>—— Skipped Build: Project: ZERO_CHECK, Configuration: Debug Win32 ——
1>Project not selected to build for this solution configuration
2>—— Build started: Project: LinuxTargets, Configuration: Debug VisualGDB ——
3>—— Skipped Build: Project: ALL_BUILD, Configuration: Debug Win32 ——
3>Project not selected to build for this solution configuration
2>VisualGDB: c:\tf\ws1\cmaketest => /tmp/VisualGDB/dwstark/cmaketest: 422 files are up-to-date.
2>VisualGDB: Run “make ” in directory “/tmp/VisualGDB/dwstark/cmaketest/VisualGDB/Debug” on dwstark@wilvm2 (SSH)
2>Scanning dependencies of target Shared
2>[ 25%] Building CXX object libShared/CMakeFiles/Shared.dir/libShared.cpp.o
2>[ 50%] Linking CXX shared library libShared.so
2>[ 50%] Built target Shared
2>Scanning dependencies of target LinuxProject2
2>[ 75%] Building CXX object NativeExe/CMakeFiles/LinuxProject2.dir/LinuxProject2.cpp.o
2>[100%] Linking CXX executable LinuxProject2
2>[100%] Built target LinuxProject2
========== Build: 1 succeeded, 0 failed, 1 up-to-date, 2 skipped ==========

And then ‘build target’ (without the clean first), works ok as it is up-to-date:

—— Build started: Project: LinuxTargets, Configuration: Debug VisualGDB ——
VisualGDB: c:\tf\ws1\cmaketest => /tmp/VisualGDB/dwstark/cmaketest: 422 files are up-to-date.
VisualGDB: Run “make libShared.so” in directory “/tmp/VisualGDB/dwstark/cmaketest/VisualGDB/Debug/libShared” on dwstark@wilvm2 (SSH)
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

Where should I start looking for how to resolve this?  It seems like this should just work?

Thanks,

Wil

[support]

Hi,

It looks like something about your target structure (names/locations of the targets) changes the default layout of the CMake-generated Makefiles and hence breaks the build command used by VisualGDB:

VisualGDB: Run “make libShared.so” in directory “/tmp/VisualGDB/dwstark/cmaketest/VisualGDB/Debug/libShared” on dwstark@wilvm2 (SSH)

VisualGDB provides 2 workarounds for this:

1. You can set the “Built all targets in a target’s subdirectory” flag under the regular VS properties (not VisualGDB Project Properties) for the CMake project (triangular CMake icon in Solution Explorer). This will change the build command from “make libShared.so” to just “make” in the target’s subdirectory.  It will be less precise than building a specific target, but still faster than building the entire solution.
2. You can try finding out the library’s target name inside the generated Makefile and set the “Advanced->Alternate Name for Building” setting under the VS properties for the library target (puzzle piece icon in Solution Explorer). This will replace the libShared.so part in the build command line.

Finally, please consider using Ninja instead of GNU Make (Ubuntu should have it available out-of-the-box). It results in faster builds and uses more predictable names for targets, eliminating the need to tweak the command line.

[Author]

Posts