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.
Related
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.
I have a CMakeLists.txt in which I want to generate several source files (namely, versiondata.cpp and version.rc.inc, included by res.rc) that depends on the general environment (current git HEAD, gcc -v output, CMakeCache.txt itself, and so on).
If it depended just on some files, I would generate it using an add_custom_command directive with the relevant DEPENDS and OUTPUT clauses; however, it's a bit tricky to pinpoint exactly its file dependencies; ideally, I'd want to run my script every time I call make, updating the files only if needed; if the generated files have actually been touched, then the targets depending from them should be rebuilt (the script is careful not to overwrite the files if they would have the same content as before).
My first attempt was using an add_custom_command with a fake main output, like this:
add_custom_command(OUTPUT versiondata.cpp.fake versiondata.cpp version.rc.inc
COMMAND my_command my_options
COMMENT "Generating versiondata.cpp"
)
# ...
# explicitly set the dependencies of res.rc, as they are not auto-deduced
set_source_files_properties(res.rc PROPERTIES OBJECT_DEPENDS "${PROJECT_BINARY_DIR}/version.rc.inc;${PROJECT_SOURCE_DIR}/other_stuff.ico")
# ...
add_executable(my_executable WIN32 ALL main.cpp versiondata.cpp res.rc)
versiondata.cpp.fake is never really generated, so the custom command is always run. This worked correctly, but always rebuilt my_executable, as CMake for some reasons automatically touches the output files (if generated) even though my script left them alone.
Then I thought I might make it work using an add_custom_target, that is automatically "never already satisfied":
add_custom_target(versiondata BYPRODUCTS versiondata.cpp version.rc.inc
COMMAND my_command my_options
COMMENT "Generating versiondata.cpp"
)
# ...
# explicitly set the dependencies of res.rc, as they are not auto-deduced
set_source_files_properties(res.rc PROPERTIES OBJECT_DEPENDS "${PROJECT_BINARY_DIR}/version.rc.inc;${PROJECT_SOURCE_DIR}/other_stuff.ico")
# ...
add_executable(my_executable WIN32 ALL main.cpp versiondata.cpp res.rc)
The idea here is that the versiondata target should be "pulled in" from the targets that depend on its BYPRODUCTS, and should be always executed. This seems to work on CMake 3.20, and the BYPRODUCTS seem to have some effect because if I remove the dependencies from my_executable my script doesn't get called.
However, on CMake 3.5 I get
make[2]: *** No rule to make target 'version.rc.inc', needed by 'CMakeFiles/my_executable.dir/res.rc.res'. Stop.
and if I remove the explicit dependency from version.rc.inc it doesn't get generated at all
[ 45%] Building RC object CMakeFiles/my_executable.dir/res.rc.res
/co/my_executable/res.rc:386:26: fatal error: version.rc.inc: No such file or directory
#include "version.rc.inc"
^
compilation terminated.
/opt/mingw32-dw2/bin/i686-w64-mingw32-windres: preprocessing failed.
CMakeFiles/my_executable.dir/build.make:5080: recipe for target 'CMakeFiles/my_executable.dir/res.rc.res' failed
make[2]: *** [CMakeFiles/my_executable.dir/res.rc.res] Error 1
so I suspect that the fact that this works in 3.20 is just by chance.
Long story short: is there some way to make this work as I wish?
In CMake there are two types of dependencies:
Target-level dependency, between targets.
A target can be build only after unconditional building of all targets it depends on.
File-level dependency, between files.
If some file is older than one of its dependencies, the file will be regenerated using corresponded COMMAND.
The key factor is that checking for timestamp of dependent files is performed strictly after building of dependent targets.
For correct regeneration of versiondata.cpp file and executable based on it, one need both dependencies:
Target-level, which would ensure that versiondata custom target
will be built before the executable.
add_dependencies(my_executable versiondata)
File-level, which will ensure that the executable will be rebuilt whenever
file versiondata.cpp will be updated.
This dependency is created automatically by listing versiondata.cpp
among the sources for the executable.
Now about BYPRODUCTS.
Even without explicit add_dependencies, your code works on CMake 3.20 because BYPRODUCTS generates needed target-level dependency automatically.
This could be deduced from the description of DEPENDS option in add_custom_target/add_custom_command:
Changed in version 3.16: A target-level dependency is added if any dependency is a byproduct of a target or any of its build events in the same directory to ensure the byproducts will be available before this target is built.
and noting, that add_executable effectively depends on every of its source files.
Because given comment for DEPENDS is applicable only for CMake 3.16 and later,
in older CMake versions BYPRODUCTS does not create target-level dependency automatically, and one need to resort to explicit add_dependencies.
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.
I want to use FADE on my computer. So, I have to use the libaws++, which is a C++ library that allows to communicate with Amazon Web Services.
OK, Here is my problem:
The website of libaws++ is unavailable. I used Google to search "libaws++" and only found libaws. I didn't know whether libaws is libaws++. They both used to communicate with Amazon Web Services. So I download libaws from sourceforge.
Here is the process I install libaws:
tar libaws-0.9.2.tar.gz
cd libaws-0.9.2
cp ~/libaws_patch_for_fade.patch libaws_patch_for_fade.patch (cp the patch to libaws-0.9.2)
patch -p2 -i libaws_patch_for_fade.patch
mkdir libawsbuild
cd libawsbuild
cmake ..
make
And error occors:
[ 28%] Building CXX object src/CMakeFiles/aws.dir/api/connectionpool.cpp.o
In file included from /home/lx/Nutstore/cloud/libaws-0.9.2/include/libaws/aws.h: 26:0,
from /home/lx/Nutstore/cloud/libaws-0.9.2/include/libaws/connec tionpool.h:22,
from /home/lx/Nutstore/cloud/libaws-0.9.2/src/api/connectionpoo l.cpp:16:
/home/lx/Nutstore/cloud/libaws-0.9.2/include/libaws/sqsresponse.h:124:9: error: a€?uint64_ta€? does not name a type
In file included from /home/lx/Nutstore/cloud/libaws-0.9.2/include/libaws/aws.h: 29:0,
from /home/lx/Nutstore/cloud/libaws-0.9.2/include/libaws/connec tionpool.h:22,
from /home/lx/Nutstore/cloud/libaws-0.9.2/src/api/connectionpoo
/home/lx/Nutstore/cloud/libaws-0.9.2/include/libaws/sqsresponse.h:124:9: error: a€?uint64_ta€? does not name a type
In file included from /home/lx/Nutstore/cloud/libaws-0.9.2/include/libaws/aws.h: 29:0,
from /home/lx/Nutstore/cloud/libaws-0.9.2/include/libaws/connec tionpool.h:22,
from /home/lx/Nutstore/cloud/libaws-0.9.2/src/api/connectionpoo l.cpp:16:
/home/lx/Nutstore/cloud/libaws-0.9.2/include/libaws/sdbresponse.h:105:20: warning: type qualifiers ignored on function return type [-Wignored-qualifiers]
.....
make[2]: *** [src/CMakeFiles/aws.dir/api/connectionpool.cpp.o] Error 1
make[1]: *** [src/CMakeFiles/aws.dir/all] Error 2
make: *** [all] Error 2
I searched on Google and stackoverflow and didn't get any useful information.
Add #include <stdint.h> to the top of those header files.
uint64_t is a standard type and should work just fine.
(Unless of course you are on some weird platform that doesn't support 64-bit integers...)
Just got this compiled with the gnu compiler 4.9.x. With newer versions of the compiler, there are more steps needed to compile libaws.
Here's what I had to do:
1) Add the following line to the header files in libaws-0.9.2/include/libaws/*.h, after all of the other include statements:
#include <stdint.h>
2) Add the following line to libaws-0.9.2/include/libaws/aws.h, after all of the other include statements:
#include <getopt.h>
3) If you're using a recent version of the Gnu C++ compiler, you'll need to modify the CMAKE files to add some flags to the compiler, so that the older C++ syntax used in libaws doesn't throw compiler errors.
Add this line to CMakeCompiler.txt, after all of the other CMAKE_CXX_FLAGS commands, around line 82 (which should be a blank line):
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fpermissive -Wignored-qualifiers")
FYI: If you're using the Gnu C compiler, you may need a similar line for the C sections, at the end of the other CMAKE commands. Something like this at the end of the file might work, but I haven't tried it:
SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fpermissive -Wignored-qualifiers")
Once those are done, here are the steps to compile:
cd libaws-0.9.2
mkdir libawsbuild
cd libawsbuild
cmake ..
make
When this is successful, you also may need to copy config.h from libawsbuild/include to libaws-0.9.2/include/libaws in order for the compiler to find config.h in the place it expects, when you compile whatever code you're writing to actually use libaws. (Although that may just have been the way my personal makefile was configured. Don't quote me on that.)
I'm creating a software project and I wanted to use autotools to do the makefile and etc. script generation for me, I manually created Makefile.am and configure.in files, and I'm using the autogen.sh script from here. The problem comes when attempting to build the project in a separate 'build' directory, e.g. if I go:
mkdir build
cd build
../configure
make
The configure step works fine, but when running make I get:
make all-recursive
Making all in src
/bin/sh: line 0: cd: src: No such file or directory
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
Any tips to get this working? Or should I give up and try something simpler/different.
I plan for this to be a reasonably simple C++ project, and the only dependency I plan to have is on the boost unit testing framework, and to do most development in Eclipse IDE.
there's a bug in your src/Makefile.am, line#17:
swin-adventure_SOURCES = src/main.cc
should really read:
swin-adventure_SOURCES = main.cc
since you are already in the src/ directory (unless there's a src/src/ subfolder)
there's another bug, as you are using special characters in your _SOURCES variabes: swin-adventure_SOURCES has the forbidden - character; try to normalize that to swin_adventure_SOURCES
finally, you are trying to assign a value to bin_PROGRAMS multiple times (and each time the same value), try to avoid that.
something like:
## Additional flags to pass to aclocal when it is invoked automatically at
## make time. The ${ACLOCAL_FLAGS} variable is picked up from the environment
## to provide a way for the user to supply additional arguments.
ACLOCAL_AMFLAGS = ${ACLOCAL_FLAGS}
## Define an executable target "swin-adventure", which will be installed into the
## directory named by the predefined variable $(bindir).
bin_PROGRAMS = swin-adventure
## Define the list of source files for the "swin-adventure" target. The file
## extension .cc is recognized by Automake, and causes it to produce rules
## which invoke the C++ compiler to produce an object file (.o) from each
## source file. The ## header files (.h) do not result in object files by
## themselves, but will be included in distribution archives of the project.
swin_adventure_SOURCES = main.cc