cmake - Using --build-and-test on add_test to build an executale - c++

I am asking this to verify that my code is implemented correctly. If it is, then that more than likely means that my library linkage is incorrect at some point, which narrows down the problem. I'm getting the following errors upon trying to build my test using make t1:
make[3]: *** No rule to make target `/home/esias/VL3/modular2/vlMain/test', needed by `vlMain/CMakeFiles/t1'. Stop.
make[2]: *** [vlMain/CMakeFiles/t1.dir/all] Error 2
make[1]: *** [vlMain/CMakeFiles/t1.dir/rule] Error 2
Suppose I would like to build executable "exec1" and test it. Ideally, this is done by tagging the executable to a target and running make <target> - please correct me if I'm wrong.
As far as I am aware, this is done by using the --build-and-test argument on add_test. This is the code I am using:
ADD_TEST(test1 exec1
--build-two-config
--build-and-test
"${CMAKE_SOURCE_DIR}/vlMain/vlMPIMain.cpp" #source to create from?
"${CMAKE_BINARY_DIR}/Tests/exec1" #output folder?
)
add_custom_target(t1 COMMAND ${CMAKE_CTEST_COMMAND} DEPENDS test1)
TARGET_LINK_LIBRARIES(t1
${GLEW_LIBRARY}
vlapp
vlrender
vldm
)
I would like to build an executable called "exec1" using ${CMAKE_SOURCE_DIR}/vlMain/vlMPIMain.cpp as source code, and put it into ${CMAKE_BINARY_DIR}/Tests/exec1 Then I would like to link a couple of libraries to it.
Is my implementation correct? Can it be improved?
Thanks.

Related

" /bin/sh: 1: Syntax error: "(" unexpected " error while building code for raspberry pi pico

I am on Ubuntu.
I am trying to build a simple project that I know worked! (I already made it work) I don't think I changed something to it but it has been three days and I cannot find a way to make it build again.
I use a library named pico-DMX, whenever I don't add it to my project with "include" in cmake, than the make starts building.
Otherwise, if I include the library in the cmake code, cmake .. command process and generate normally but the build ctrying to build a simple project that I know workedrashes instantaneously. I cannot seem to understand where it comes from.
This is the error message:
PICO_SDK_PATH is /home/andrew/pico/pico-sdk
PICO platform is rp2040.
Build type is Release
PICO target board is pico.
Using board configuration from /home/andrew/pico/pico-sdk/src/boards/include/boards/pico.h
TinyUSB available at /home/andrew/pico/pico-sdk/lib/tinyusb/src/portable/raspberrypi/rp2040; enabling build support for USB.
cyw43-driver available at /home/andrew/pico/pico-sdk/lib/cyw43-driver
lwIP available at /home/andrew/pico/pico-sdk/lib/lwip
-- Configuring done
-- Generating done
-- Build files have been written to: /home/andrew/pico/serial_pico (copy)/build
Scanning dependencies of target bs2_default
[ 1%] Building ASM object pico-sdk/src/rp2_common/boot_stage2/CMakeFiles/bs2_default.dir/compile_time_choice.S.obj
[ 2%] Linking ASM executable bs2_default.elf
/bin/sh: 1: Syntax error: "(" unexpected
make[2]: *** [pico-sdk/src/rp2_common/boot_stage2/CMakeFiles/bs2_default.dir/build.make:98: pico-sdk/src/rp2_common/boot_stage2/bs2_default.elf] Error 2
make[2]: *** Deleting file 'pico-sdk/src/rp2_common/boot_stage2/bs2_default.elf'
make[1]: *** [CMakeFiles/Makefile2:1493: pico-sdk/src/rp2_common/boot_stage2/CMakeFiles/bs2_default.dir/all] Error 2
make: *** [Makefile:91: all] Error 2
This is my main cmake files:
cmake_minimum_required(VERSION 3.13)
include($ENV{PICO_SDK_PATH}/pico_sdk_init.cmake)
project(usb_control C CXX ASM)
set(CMAKE_CXX_STANDARD 17)
pico_sdk_init()
include($ENV{HOME}/pico/libraries/lib/Pico-DMX/interfaceLibForPicoSDK.cmake)
add_executable(usb_control
main.cpp
)
target_link_libraries(usb_control picodmx pico_stdlib hardware_pio hardware_dma)
pico_enable_stdio_usb(usb_control 1)
pico_enable_stdio_uart(usb_control 0)
pico_add_extra_outputs(usb_control)
The previous cmake file include $ENV{HOME}/pico/libraries/lib/Pico-DMX/interfaceLibForPicoSDK.cmake which contains :
## Include this file if you want to use the Pico-DMX library
## in YOUR (Pico-C-SDK-based) project.
cmake_minimum_required(VERSION 3.12)
# Define the Pico-DMX library
add_library(picodmx INTERFACE)
target_sources(picodmx INTERFACE
${CMAKE_CURRENT_LIST_DIR}/src/DmxInput.cpp
${CMAKE_CURRENT_LIST_DIR}/src/DmxOutput.cpp
)
pico_generate_pio_header(picodmx
${CMAKE_CURRENT_LIST_DIR}/extras/DmxInput.pio
)
pico_generate_pio_header(picodmx
${CMAKE_CURRENT_LIST_DIR}/extras/DmxOutput.pio
)
target_include_directories(picodmx INTERFACE
${CMAKE_CURRENT_LIST_DIR}/src
)
Again, I know there are no mistakes in the C++ code, it worked! It started to bug and wouldn't work again when I played with the Cmake to include directly the library dependencies of pico-dmx in its cmake file.
If you have any questions feel free to ask, I'll answer quickly. In advance thank you for your help
As mentioned in the comments, the cause is the name of your directory. In order to accurately explain why it happens, I reproduced your situation myself. I created a dummy project under "/tmp/test checkout (copy)" and built using CMake:
cd "/tmp/test checkout (copy)/build/pico-sdk/src/rp2_common/boot_stage2" && \
arm-none-eabi-objdump -h /tmp/test\ checkout\ (copy)/build/pico-sdk/src/rp2_common/boot_stage2/bs2_default.elf >bs2_default.dis
Note that the spaces in the full filename are correctly escaped with a backslash, but the parentheses are not. This confuses the shell.
I raised this issue on the Pico SDK. Until it is fixed, (EDIT: it was fixed in Dec 2022) people should steer clear of using special characters in their directory structures. This is a good recommendation in general as it avoids situations like these.

CMake illogic path parsing?

I'm trying to include this project into my cmake code base.
I cloned the repo to my include/ dir and added this line to my CMakeLists.txtx:
add_subdirectory(${DIVISIBLE_INSTALL_INCLUDE_DIR}/cc.ublox.commsdsl)
include_directories(${DIVISIBLE_INSTALL_INCLUDE_DIR})
link_directories(${DIVISIBLE_INSTALL_INCLUDE_DIR})
But when I try to rebuild my project it says that it can't find the defined scheme files:
[WARNING]: failed to load external entity "/Users/pete/Documents/projekte/simple-dgps/dsl/main.xml"
If I add the project prefix(PROJECT_SOURCE_DIR) to the scheme files path the path appears twice.
ERROR: Failed to parse/Users/pete/Documents/projekte/simple-dgps/Users/pete/Documents/projekte/simple-dgps/include/cc.ublox.commsdsl/dsl/main.xml
And if I fill the missing part between simple-dgps and dsl (which would be include/cc.ublox.commsdsl) I get this error:
make[2]: *** No rule to make target `include/cc.ublox.commsdsl/include/cc.ublox.commsdsl/dsl/main.xml', needed by `output.tmp'. Stop.
make[1]: *** [include/cc.ublox.commsdsl/CMakeFiles/cc.ublox.commsdsl.dir/all] Error 2
make: *** [all] Error 2
Assuming that the first error relates to a wrong file location, what does the second mean then(although it clearly has the wrong path because it exists twice)
The problem definitely seems to be with defining the project path for cc.ublox.commsdsl vs the project path for your project.
If I add the project prefix(PROJECT_SOURCE_DIR) to the scheme files path the path appears twice.
Can you share what you added? /Users/pete/Documents/projekte/simple-dgps/include/cc.ublox.commsdsl/dsl/main.xml looks right for the cc.ublox.commsdsl path - but it seems you may have added the path such that it gets duplicated. Hard to tell what's wrong without looking at what you added.
Found the problem for the double path problem.
I added the project as subdir from my main project by adding this line:
add_subdirectory(${DIVISIBLE_INSTALL_INCLUDE_DIR}/cc.ublox.commsdsl)
The problem is that DIVISIBLE_INSTALL_INCLUDE_DIR is a absolute path and thus is added to the cmake source dir of the subdir.
This can be fixed by using:
add_subdirectory(include/cc.ublox.commsdsl)

Building mathgl on windows

I am kind of new to C++ (used to be a Java developer, where this is way easier...) and I have to write an application, which has to plot some graphs and charts. To do so I want to use the MathGL library. And I learned, that I have to compile it myself in order to use it. So that's what I'm trying to do the last few days...
I am using Windows with MinGW and the CLion IDE.
I started by extracting MathGL's source code into a folder and opening the folder with CLion.
Then I downloaded the source codes of zlib and libpng and set the INCLUDE_DIR variables in the MathGL project to the respective folders and PNG_PNG_LIBRARY to png32. When I try to compile mgl_example via CLion it gives me the following error:
In file included from [...]\mathgl-2.3.5.1\src\data_png.cpp:22:0:
[...]/libpng-1.6.29/png.h:361:27: fatal error: pnglibconf.h: No such file or directory
compilation terminated.
mingw32-make.exe[2]: *** [src/CMakeFiles/mgl.dir/data_png.cpp.obj] Error 1
mingw32-make.exe[2]: *** Waiting for unfinished jobs....
src\CMakeFiles\mgl.dir\build.make:465: recipe for target 'src/CMakeFiles/mgl.dir/data_png.cpp.obj' failed
mingw32-make.exe[2]: Leaving directory '[..]/mathgl-2.3.5.1/cmake-build-debug'
mingw32-make.exe[1]: *** [src/CMakeFiles/mgl.dir/all] Error 2
mingw32-make.exe: *** [all] Error 2
CMakeFiles\Makefile2:89: recipe for target 'src/CMakeFiles/mgl.dir/all' failed
mingw32-make.exe[1]: Leaving directory '[...]/mathgl-2.3.5.1/cmake-build-debug'
Makefile:129: recipe for target 'all' failed
EDIT: I managed to fix that first error by copying the prebuilt pnglibconf.h from the scripts directory of the libpng source code. After that the definition of byte in the MinGW header rpcndr.h seems to interfer with the byte(double) method in oPRCFile.cc, which I just fixed by renaming the method to byteN and calling it from a macro (#define byte(c) byteN(c)). Although this might not be the right way to go, it works.
But having that all fixed the linker seems to be configured wrongly: it says cannot find -lpng32. How can I fix that one?
EDIT: Alright, it's compiled. So I copied libmgl.a and put it into the project I want to use it it. I linked against it with cmake by calling target_link_libraries(Test ${CMAKE_SOURCE_DIR}/libmgl.a) but it just throws a bunch of undefined reference to errors (same if I use the procompiled binaries):
MakeFiles\Test.dir/objects.a(main.cpp.obj): In function `ZN8mglDataAC2Ev':
c:/mingw/include/mgl2/abstract.h:156: undefined reference to `_imp___ZTV8mglDataA'
CMakeFiles\Test.dir/objects.a(main.cpp.obj): In function `ZN8mglDataAD2Ev':
c:/mingw/include/mgl2/abstract.h:157: undefined reference to `_imp___ZTV8mglDataA'
[...]
It looks like that missing header file is generated after running a configure for libpng (which under Windows you may be unable to do and need to generate yourself -> Cannot open include file: 'pnglibconf.h':No such file or directory)
But besides that, how did you get the impression that you need to build it from scratch in order to use it? You can also download the precompiled binaries and link them with your program (http://mathgl.sourceforge.net/doc_en/Installation.html - point 2).
edit: Looking at your edit, you need to specify the actual library file in Windows (probably something along the lines of png32.a or whatever your libpng compilation generated), assuming the linker also has the path where the library file is (see http://www.mingw.org/wiki/specify_the_libraries_for_the_linker_to_use)

Required prebuild rule in generic Makefile

I'm compiling C++ code for Webots (a robotic simulator), by means of makefiles, and I'm using the generic makefile Makefile.include Webots supplies to ease the process.
I build by own makefile, set a bunch of required variables and then call that makefile that sets all the necessary rules for compilation. That's how it was supposed to work anyway.
I'm getting the following error:
make[1]: *** No rule to make target 'USER_PREBUILD'. Stop.
/usr/share/webots/resources/Makefile.include:503: recipe for target 'pre-build' failed
make: *** [pre-build] Error 2
And looking at the relevant line (from Makefile.include):
$(SUPPORTED_TARGETS): post-build
USER_PREBUILD:
USER_POSTBUILD:
pre-build:
#$(MAKE) --silent USER_PREBUILD
post-build: main-build
#$(MAKE) --silent USER_POSTBUILD
$(TARGETS): pre-build
main-build: $(TARGETS)
I'm not sure if there is not a syntax error when calling make in the pre-build and post-build, or if USER_PREBUILD and USER_POSTBUILD are supposed to be concrete files, but even if replace them with $(USER_PREBUILD) I get *** No targets specified and no makefile found.
So I assume I would need to set those variables before calling the external makefile, but what exactly is the syntax if I don't have anything to be done before building?
Strangely, even despite these errors, the program compiles (I get the *.o, *.d and the binary on the build folder), but it never copies the binary to the destination folder.
That's a bit of an odd way to have set things up in that file.
The USER_PREBUILD: and USER_POSTBUILD: lines have no effect and are not doing anything for anyone (at least that I'm aware of).
You have two choices for how to solve this problem.
You can provide empty rules for the USER_PREBUILD and USER_POSTBUILD targets in your makefile:
USER_PREBUILD USER_POSTBUILD: ;
or you can avoid even the attempt at running those targets (at the cost of an over-riding warning message from make) by using these lines:
pre-build: ;
post-build: main-build ;
in your makefile after the inclusion of Makefile.include.

Compiling clang-llvm examples

I am trying to compile the Hello example in directory lib/Transforms/Hello, which is basically a Hello World of LLVM pass, but I get the following error when I try to compile it using make.
../../../Makefile.common:61: ../../../Makefile.config: No such file or directory
../../../Makefile.common:69: /Makefile.rules: No such file or directory
make: *** No rule to make target `/Makefile.rules'. Stop.
Any idea what is the problem and how to fix it?
If you built LLVM + Clang according to instructions, the Hello sample should have already been built. Go to lib/Transforms/Hello in the build directory (where you ran configure and then make). There should be a Debug+Asserts (or whatever configuration you compiled) there. And you can also run make from there again.
In general, you always make from the build directory, not the source directory. The build directory has all the Makefiles properly set up.