CMake successful, resulting makefile error - opengl

This is a follow-up question to one that I asked previously, which if it pleases you may be found here. To summarize, I have been trying to understand the build process for linking necessary libraries into OpenGL. I am aware that there are boilerplates and other methods that make this process easier; I am interested in being able to do so autonomously.
My issue is that although CMake sucessfully processes my CMakeLists.txt file, the resulting Makefile throws an error. If helpful, my file structure is
contextualized here:
+ infuriating_project
+ bin // post compile results
+ src // my humble code
+ deps // external code
+glew
+ include
+ src
+glfw
+ include
+ src
+glm
+soil
+ lib
+ src
Here are the contents of my CMakeLists.txt file:
cmake_minimum_required (VERSION 3.0)
# Version Information ---------------------------------------------------------
project (openGL-practice)
SET (VERSION_MAJOR 1)
SET (VERSION_MINOR 0)
SET (VERSION_FEATURE 0)
SET (VERSION_PATCH 0)
SET (VERSION "${VERSION_MAJOR}.${VERSION_MINOR}")
SET (VERSION "${VERSION}.${VERSION_FEATURE}.${VERSION_PATCH}")
MESSAGE ("Version: ${VERSION}")
# Configure Binary Directories ------------------------------------------------
SET (PROJECT_BINARY_DIR "${PROJECT_BINARY_DIR}/bin")
MESSAGE ("Source path: ${PROJECT_SOURCE_DIR}")
MESSAGE ("Binary path: ${PROJECT_BINARY_DIR}")
# Configure Depenency Directories ---------------------------------------------
SET (deps "${PROJECT_SOURCE_DIR}/deps")
MESSAGE ("Dependencies path: ${deps}")
SET (glew_inc "${deps}/glew/include/GL/")
SET (glew_src "${deps}/glew/src/")
SET (glfw_inc "${deps}/glfw/include/GLFW/")
SET (glfw_src "${deps}/glfw/src/")
SET (glm "${deps}/glm/glm/")
SET (soil_lib "${deps}/lib/")
SET (soil_src "${deps}/src/")
# Include directories ---------------------------------------------------------
include_directories("
${PROJECT_SOURCE_DIR}
${glew_inc}
${glew_src}
${glfw_inc}
${glfw_src}
${glm}
${soil_lib}
${soil_src}
")
# Add executable --------------------------------------------------------------
add_executable(main ${PROJECT_SOURCE_DIR}/src/main.cpp)
Upon completion, I get the following error when running make:
CMakeFiles/main.dir/flags.make:10: *** missing separator. Stop.
make[1]: *** [CMakeFiles/main.dir/all] Error 2
make: *** [all] Error 2
My investigations of this error have led me to believe that there is a syntax error, likely a tabs vs spaces error as indicated here. I am sure that this is an issue on my behalf, and not a bug in CMake. I am confident that there should be a way to alter my CMakeLists file such that this issue does not occur.
The Makefile is a bit lengthy for this already lengthy post. If it would be helpful for me to upload it, I can edit this question with that information. Thank you very much in advance for any and all help or advice.

This is wrong:
include_directories("
${PROJECT_SOURCE_DIR}
${glew_inc}
${glew_src}
${glfw_inc}
${glfw_src}
${glm}
${soil_lib}
${soil_src}
")
Do not quote this as one long string: cmake will try to provide this string (including newlines) as the argument to -I in your compiler.
Use:
include_directories(
${PROJECT_SOURCE_DIR}
${glew_inc}
${glew_src}
${glfw_inc}
${glfw_src}
${glm}
${soil_lib}
${soil_src}
)
Or, quote each path individually if you want to.

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)

No rule to make target `libbrcmEGL.so', needed by `HelloTriangle'

I'm trying to cross-compile an OpenGLES2.0 example HelloTriangle using VisualGDB for the RaspberryPi 3 running Raspbian lite.
I assume I was able to include the libraries libbrcmEGL.so and libbrcmGLESv2.so correctly in my CMakeLists.txt file
because instead of giving me these errors:
c:/sysgcc/raspberry/bin/../lib/gcc/arm-linux-gnueabihf/6/../../../../arm-linux-gnueabihf/bin/ld.exe: cannot find -lLIBGLES
c:/sysgcc/raspberry/bin/../lib/gcc/arm-linux-gnueabihf/6/../../../../arm-linux-gnueabihf/bin/ld.exe: cannot find -lLIBEGL`
It gives me these errors
make[2]: *** No rule to make target `libbrcmEGL.so', needed by `HelloTriangle'. Stop.`
This is my CMakeLists file:
cmake_minimum_required(VERSION 2.7)
project(HelloTriangle)
set(LIBRARIES_FROM_REFERENCES "")
add_executable(HelloTriangle HelloTriangle.cpp esShapes.c esTransform.c esUtil.c esShader.c)
include_directories(include)
target_link_libraries(HelloTriangle ${CMAKE_BINARY_DIR}/libbrcmGLESv2.so ${CMAKE_BINARY_DIR}/libbrcmEGL.so "${LIBRARIES_FROM_REFERENCES}")
I don't understand what else it needs to make the target. Looking around stack overflow, I saw suggestions to add
LINK_DIRECTORIES(/opt/vc/lib/)
I also tried
target_link_libraries(HelloTriangle /opt/vc/lib/libbrcmGLESv2.so /opt/vc/lib/libbrcmEGL.so "${LIBRARIES_FROM_REFERENCES}")
I also checked that I have these libraries in my sysroot in:
C:\SysGCC\raspberry\arm-linux-gnueabihf\sysroot
I still get the same error:
I need some help figuring out what is missing from my CMakeLists.txt
Changed to target_link_libraries(HelloTriangle ${CMAKE_CURRENT_SOURCE_DIR}/lib/libbrcmGLESv2.so ${CMAKE_CURRENT_SOURCE_DIR}/lib/libbrcmEGL.so "${LIBRARIES_FROM_REFERENCES}") and it compiled

Using autotools build system / Building in a separate 'build' directory

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

CMake FIND_PACKAGE succeeds but returns wrong path

I'm trying to have CMake 2.8.6 link to boost::program_options using the following code in my CMakeLists.txt
FIND_PACKAGE(Boost COMPONENTS program_options REQUIRED)
INCLUDE_DIRECTORIES (${Boost_INCLUDE_DIR})
ADD_EXECUTABLE (segment segment.cpp)
TARGET_LINK_LIBRARIES (segment ${Boost_LIBRARIES})
The find command seems to succeed but passes the wrong directory to the linker. The package is actually in:
`/usr/lib64/libboost_program_options-mt.so.5`
but CMakeFiles/segment.dir/link.txt lists the following:
/cm/shared/apps/gcc/4.4.6/bin/c++ CMakeFiles/segment.dir/segment.cpp.o -o segment -rdynamic /usr/lib64/lib64/libboost_program_options-mt.so.5 -lpthread -lrt -Wl,-rpath,/usr/lib64/lib64
Note the extra lib64 in the path. Also, the -l flag in front of the path seems to be missing.
When running CMake it reports that it correctly finds the package, and the {$Boost_LIBRARIES} variable seems to list the correct libs:
Boost found.
Found Boost components:
program_options
${Boost_LIBRARIES} - optimized;boost_program_options-mt-shared;debug;boost_program_options-mt-shared-debug
The generated CMakeCache.txt file starts with:
//The directory containing a CMake configuration file for Boost.
Boost_DIR:PATH=/usr/lib64/boost
//Boost include directory
Boost_INCLUDE_DIR:FILEPATH=/usr/include
Which seems to be correct. But when running make it uses the path in link.txt above and I get the error:
make[2]: *** No rule to make target `/usr/lib64/lib64/libboost_program_options-mt.so.5', needed by `segment'. Stop.
make[1]: *** [CMakeFiles/segment.dir/all] Error 2
make: *** [all] Error 2
What might cause this extra injection of a subdir into the path? What might cause link.txt to be generated in this way? And how do I fix it (or work around it)?
This problem occurs when using some older versions of boost with cmake-2.8.6-rc2 or later, where the boost package finding code was changed.
The problem can be worked around by specifying -DBoost_NO_BOOST_CMAKE=ON on the cmake command line.
The actual commit where this problem is introduced is 7da796d1fdd7cca07df733d010cd343f6f8787a9, and can be viewed here.
The problem is with the boost-devel distributed file: /usr/lib64/boost/Boost-relwithdebinfo.cmake
The cmake-2.6 package does not use this file at all, because the FindBoost.cmake file returns (correct) full-paths to boost libraries. The cmake28-2.8.8 FindBoost.cmake file returns library strings like "boost_date_time-mt-shared", which are targets defined in /usr/lib64/boost/Boost-relwithdebinfo.cmake.
At the very top of /usr/lib64/boost/Boost-relwithdebinfo.cmake, a variable named _IMPORT_PREFIX is defined from the location of the cmake file itself, and then used like so:
#----------------------------------------------------------------
# Generated CMake target import file for configuration "RelWithDebInfo".
#----------------------------------------------------------------
# Commands may need to know the format version.
SET(CMAKE_IMPORT_FILE_VERSION 1)
# Compute the installation prefix relative to this file.
GET_FILENAME_COMPONENT(_IMPORT_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH)
GET_FILENAME_COMPONENT(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
# Import target "boost_date_time-static" for configuration "RelWithDebInfo"
SET_PROPERTY(TARGET boost_date_time-static APPEND PROPERTY IMPORTED_CONFIGURATIONS RELWITHDEBINFO)
SET_TARGET_PROPERTIES(boost_date_time-static PROPERTIES
IMPORTED_LOCATION_RELWITHDEBINFO "${_IMPORT_PREFIX}/lib64/libboost_date_time.a"
)
This sets _IMPORT_PREFIX to "/usr/lib64", which is concatenated with another string that has /lib64/ in it as well. I found that if I simply change the file to include a 3rd GET_FILENAME_COMPONENT call, it works fine. Like so:
#----------------------------------------------------------------
# Generated CMake target import file for configuration "RelWithDebInfo".
#----------------------------------------------------------------
# Commands may need to know the format version.
SET(CMAKE_IMPORT_FILE_VERSION 1)
# Compute the installation prefix relative to this file.
GET_FILENAME_COMPONENT(_IMPORT_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH)
GET_FILENAME_COMPONENT(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
GET_FILENAME_COMPONENT(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
# Import target "boost_date_time-static" for configuration "RelWithDebInfo"
SET_PROPERTY(TARGET boost_date_time-static APPEND PROPERTY IMPORTED_CONFIGURATIONS RELWITHDEBINFO)
SET_TARGET_PROPERTIES(boost_date_time-static PROPERTIES
IMPORTED_LOCATION_RELWITHDEBINFO "${_IMPORT_PREFIX}/lib64/libboost_date_time.a"
)
This seems to be an issue with CMake 2.8.6 on CentOS. When doing the same with 2.6.4 or 2.8.3 it works correctly. Also with 2.8.7 on OS X it also works correctly.
I also see the problem on the pre-compiled cmake version 2.8.8 using CentOS 64-bit 6.2
I noticed this issue on cmake version 2.8.11.2 with boost-1.41.0-18.el6.x86_64
The approved answer does not seem satisfactory because appending this define to the cmake runtime I get:
CMake Warning:
Manually-specified variables were not used by the project:
Boost_NO_BOOST_CMAKE
I can't seem to comment or downvote due to not participating in stackoverflow enough. That is a chicken and egg problem!
I also can't seem to upvote the explanation by Kai Meyer. However, I think this really explains the problem.
From what I am gathering it seems that in summary, FindBoost.cmake provided by CMake seems to all of a sudden fail to find Boost, so the find code is now searching via the boost provided script for cmake, which in turn has a bug and seems to not return the correct path.
while building package from AUR following prefix helped to find Boost:
BOOST_ROOT=/usr
example:
BOOST_ROOT=/usr makepkg -si