I hate cmake, as I always seem to spend more time trying to get cmake to compile and build a program than I do writing and debugging the program cmake is supposed to be building.
Anyway, the latest problem is this.
I have some code that starts ...
#include <mrpt/obs/CObservationBatteryState.h>
#include <mrpt/obs/CObservationComment.h>
#include <mrpt/obs/CObservation2DRangeScan.h>
#include <mrpt/maps/CSimplePointsMap.h>
#include <mrpt/comms/CSerialPort.h>
#include <mrpt/poses/CPose3D.h>
#include <mrpt/system/os.h>
a fairly simple CMakeLists.txt that looks like...
project(some_sort_of_name)
cmake_minimum_required(VERSION 3.8)
find_package(MRPT COMPONENTS obs maps comms )
if(CMAKE_COMPILER_IS_GNUCXX AND NOT CMAKE_BUILD_TYPE MATCHES "Debug")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -O3")
endif()
add_executable(lidar lidar.c)
add_executable(lidar_obs lidar_obs.cpp)
target_link_libraries(lidar_obs mrpt::obs mrpt::maps)
And the compilation fails with...
[ 50%] Built target lidar
[ 75%] Building CXX object CMakeFiles/lidar_obs.dir/lidar_obs.cpp.o
/home/mike/work/minipupper/lidar/lidar_obs.cpp:5:10: fatal error: mrpt/comms/CSerialPort.h: No such file or directory
5 | #include <mrpt/comms/CSerialPort.h>
So it is happy with compiling & building "lidar" which is a simple 'C' program with no calls to MRPT, but when it comes to compiling lidar_obs, it is happy to find the include files for obs and maps but not comms.
The include files are there, i.e.
$ ls /usr/include/mrpt/comms/include/mrpt
comms comms.h
$ ls /usr/include/mrpt/comms/include/mrpt/comms
CClientTCPSocket.h CInterfaceFTDI.h CSerialPort.h CServerTCPSocket.h net_utils.h nodelets.h registerAllClasses.h
just like e.g. obs & maps
$ ls /usr/include/mrpt/obs
include
$ /usr/include/mrpt/obs/include
mrpt
$ ls /usr/include/mrpt/obs/include/mrpt
maps obs obs.h
$ ls /usr/include/mrpt/obs/include/mrpt/maps
CMetricMapEvents.h CMetricMap.h CSimpleMap.h metric_map_types.h TMetricMapInitializer.h TMetricMapTypesRegistry.h
What is going on with cmake ? How does it find some files and not others.
You were missing the link command to also include the mrpt-comms library:
target_link_libraries(lidar_obs mrpt::obs mrpt::maps mrpt::comms)
# ^^^^^^^^^^^
CMake with exported libraries work like that: "linking" an imported cmake target, also includes the "-I" flags (for #includes) apart of the link -l flags themselves.
Related
During my build process, a file generated by add_custom_command must the be compiled as C++. That's working but the generated file contains an include directive. When I modify the included file, the generated file is not recompiled.
There is an option IMPLICIT_DEPENDS for add_custom_command. But it does remake the generated file instead of just compiling it. And the documentation has a note
Note that the IMPLICIT_DEPENDS option is currently supported only for Makefile generators and will be ignored by other generators.
What's the recommended way to be able to recompile the generated file without remaking it and without depending on a given generator?
An example:
% more foo.h
#ifndef FOO_H
#define FOO_H
int const value = 36;
#endif
% more foo.in
#include "foo.h"
#include <iostream>
int main()
{
std::cout << "The answer is " << value << '\n';
return 0;
}
% more CMakeLists.txt
cmake_minimum_required(VERSION 3.15)
project(Test)
add_custom_command(OUTPUT foo.cpp
DEPENDS foo.in
COMMAND cp ${CMAKE_CURRENT_SOURCE_DIR}/foo.in foo.cpp)
set_source_files_properties(foo.cpp PROPERTIES INCLUDE_DIRECTORIES ${CMAKE_CURRENT_SOURCE_DIR})
add_executable(foo foo.cpp)
% mkdir build
% cd build
% cmake ..
...
% make
[ 33%] Generating foo.cpp
Scanning dependencies of target foo
[ 66%] Building CXX object CMakeFiles/foo.dir/foo.cpp.o
[100%] Linking CXX executable foo
[100%] Built target foo
% ./foo
The answer is 36
% sed -i.bak -e 's/36/42/' ../foo.h
% make
[100%] Built target foo
% ./foo
The answer is 36
I expect the second make to recompile foo.cpp (but not to regenerate it) so that the answer is 42.
Adding
IMPLICIT_DEPENDS CXX ${CMAKE_CURRENT_SOURCE_DIR}/foo.in
to the CMakeLists.txt generates a correct executable but regenerates foo.cpp when not needed and it not available for other generators according to the documentation.
I'm testing vcpkg (on macOS) with a CMake project.
Since not all vcpkg packages have CMake find modules, I'm trying with a package that doesn't have one: libuuid
This is the directory tree relative to libuuid I can see from the vcpkg root:
$ find packages/libuuid_x64-osx
packages/libuuid_x64-osx
packages/libuuid_x64-osx/include
packages/libuuid_x64-osx/include/uuid
packages/libuuid_x64-osx/include/uuid/uuid.h
packages/libuuid_x64-osx/BUILD_INFO
packages/libuuid_x64-osx/lib
packages/libuuid_x64-osx/lib/libuuid.a
packages/libuuid_x64-osx/CONTROL
packages/libuuid_x64-osx/debug
packages/libuuid_x64-osx/debug/lib
packages/libuuid_x64-osx/debug/lib/libuuid.a
packages/libuuid_x64-osx/share
packages/libuuid_x64-osx/share/libuuid
packages/libuuid_x64-osx/share/libuuid/copyright
Example program:
#include <iostream>
#include <uuid/uuid.h>
int main(int argc, char **argv)
{
std::cout << "Hello, world!" << std::endl;
return 0;
}
Example CMakeLists.txt
cmake_minimum_required(VERSION 3.13)
project(vcpkg_example_project)
add_executable(app app.cpp)
target_link_libraries(app uuid)
If I understand correctly, vcpkg's philosophy is not to provide missing CMake find-modules, but to simply have #include <libfoo/foo.h> work out of the box. And in fact the example above compiles fine. But fails to find -luuid:
$ cmake -DCMAKE_TOOCHAIN_FILE=/Users/me/Dev/vcpkg/scripts/buildsystems/vcpkg.cmake ..
...
$ cmake --build .
Scanning dependencies of target app
[ 50%] Building CXX object CMakeFiles/app.dir/app.cpp.o
[100%] Linking CXX executable app
ld: library not found for -luuid
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [app] Error 1
make[1]: *** [CMakeFiles/app.dir/all] Error 2
make: *** [all] Error 2
What am I missing?
Also, I see there is a installed/x64-osx/lib/libuuid.a. Shouldn't installed/x64-osx/lib automatically added as lib path by the toolchain cmake script?
I'd make a target out of uuid. From what you describe, most probably an Interface Library called uuid. You can add_target_include_directories and target_link_libraries for the headers and any libraries, and then add it to the rest of your project.
So something like this:
add_library(uuid INTERFACE)
if(${CMAKE_BUILD_TYPE} STREQUAL "Release")
find_library(LIBUUID uuid "${CMAKE_CURRENT_SOURCE_DIR}/packages/libuuid_x64-osx/lib/")
else()
find_library(LIBUUID uuid "${CMAKE_CURRENT_SOURCE_DIR}/packages/libuuid_x64-osx/debug/lib/")
endif()
target_link_libraries(uuid INTERFACE "${LIBUUID}")
target_include_directories(uuid SYSTEM INTERFACE "${CMAKE_CURRENT_SOURCE_DIR}/packages/libuuid_x64-osx/include")
I'd then do an add_subdirectory to the library's folder and link to uuid
I am trying to create and compile an ARM-based STM32 project using CMake.
CMakeLsts.txt is the following:
cmake_minimum_required(VERSION 3.7)
SET(CMAKE_SYSTEM_NAME Generic)
SET(CMAKE_SYSTEM_VERSION 1)
# Enable logging messages
#set(CMAKE_VERBOSE_MAKEFILE ON)
# Project name
set(PROJECT_NAME FixtureTACO)
PROJECT(${PROJECT_NAME} C CXX ASM)
SET(CMAKE_CXX_STANDARD 11)
###################### CHIP CONFIGURATION ##########################
SET(ROOT_PROJ ${CMAKE_CURRENT_SOURCE_DIR})
SET(CPU "cortex-m4")
SET(ARCH_NAME "arm")
SET(ARCH_VER "v7e-m")
SET(FAMILY "stm32f3")
SET(CHIP "STM32F303xC")
SET(ARCH "${ARCH_NAME}${ARCH_VER}")
####################################################################
# MCU Config
set(FPU "-mfpu=fpv4-sp-d16")
set(FLOAT_ABI "-mfloat-abi=hard")
# Toolchain path
set(TOOLCHAIN_PATH "")
set(ARM_LIB "/usr/lib/arm-none-eabi/lib/${ARCH}")
# Specify C, C++ and ASM compilers
SET(CMAKE_C_COMPILER ${TOOLCHAIN_PATH}arm-none-eabi-gcc)
SET(CMAKE_CXX_COMPILER ${TOOLCHAIN_PATH}arm-none-eabi-g++)
set(AS ${TOOLCHAIN_PATH}arm-none-eabi-as)
set(AR ${TOOLCHAIN_PATH}arm-none-eabi-ar)
set(OBJCOPY ${TOOLCHAIN_PATH}arm-none-eabi-objcopy)
set(OBJDUMP ${TOOLCHAIN_PATH}arm-none-eabi-objdump)
set(SIZE ${TOOLCHAIN_PATH}arm-none-eabi-size)
set(GDB ${TOOLCHAIN_PATH}arm-none-eabi-gdb)
set(SIZE ${TOOLCHAIN_PATH}arm-none-eabi-size)
# Definitions passed at compile time (#defines)
add_definitions(-DFAMILY=${FAMILY})
add_definitions(-DCHIP=${CHIP})
add_definitions(-D${CHIP})
add_definitions(-DUSE_FULL_LL_DRIVER)
add_definitions(-USE_HAL_DRIVER)
add_definitions(-DHSE_VALUE=8000000)
add_definitions(-DHSE_STARTUP_TIMEOUT=100)
add_definitions(-DLSE_STARTUP_TIMEOUT=5000)
add_definitions(-DLSE_VALUE=32768)
add_definitions(-DHSI_VALUE=8000000)
add_definitions(-DLSI_VALUE=40000)
add_definitions(-DDD_VALUE=3300)
add_definitions(-DPREFETCH_ENABLE=1)
# Compilation flags
add_compile_options(-mcpu=${CPU})
add_compile_options(-march=${ARCH})
add_compile_options(-mthumb)
add_compile_options(${FPU})
add_compile_options(${FLOAT_ABI})
add_compile_options(-Og)
add_compile_options(-Wall)
add_compile_options(-fdata-sections)
add_compile_options(-ffunction-sections)
# Only for debugging
add_compile_options(-g -gdwarf-2)
# Linker script path
file(GLOB_RECURSE LINKER_SCRIPT ${ROOT_PROJ}/platforms/${FAMILY}/Linker/*.ld)
# Variables initialized first time
SET(CMAKE_CXX_FLAGS_INIT "-std=c++11")
SET(CMAKE_C_FLAGS_INIT "-std=gnu99")
################################## Source code ###############################################################
# Retrieve all sources # "platforms/${FAMILY}/Startup/*.s"
file(GLOB SOURCES "platforms/${FAMILY}/Startup/*.s" "src/*.cpp" "src/*.c" "platforms/${FAMILY}/Hal/src/*.c" "platforms/${FAMILY}/Device/*.c")
#Retrieve all locations of headers
file(GLOB_RECURSE HEADERS "includes/*.h" "src/*.h" "platforms/${FAMILY}*.h")
set (INCLUDE_DIRS "")
foreach (_headerFile ${HEADERS})
get_filename_component(_dir ${_headerFile} PATH)
list (APPEND INCLUDE_DIRS ${_dir})
endforeach()
list(REMOVE_DUPLICATES INCLUDE_DIRS)
include_directories(${INCLUDE_DIRS})
link_directories(${ARM_LIB})
################################## Source code END ###########################################################
set(EXE_NAME "${PROJECT_NAME}_${CHIP}")
add_executable(${EXE_NAME}.elf ${SOURCES} ${LINKER_SCRIPT})
set(CMAKE_EXE_LINKER_FLAGS "-mcpu=${CPU} -mthumb ${FPU} ${FLOAT_ABI} --specs=nano.specs -T${LINKER_SCRIPT} -Wl,-Map=${PROJECT_BINARY_DIR}/${PROJECT_NAME}.map,--cref -Wl,--gc-sections")
# Libs and external dependencies
target_link_libraries(${EXE_NAME}.elf -lc -lm -lnosys)
# Outputs
set(ELF_FILE ${PROJECT_BINARY_DIR}/${EXE_NAME}.elf)
set(HEX_FILE ${PROJECT_BINARY_DIR}/${EXE_NAME}.hex)
set(BIN_FILE ${PROJECT_BINARY_DIR}/${EXE_NAME}.bin)
add_custom_command(TARGET "${EXE_NAME}.elf" POST_BUILD
# Build .hex and .bin files
COMMAND ${OBJCOPY} -Obinary ${ELF_FILE} ${BIN_FILE}
COMMAND ${OBJCOPY} -Oihex ${ELF_FILE} ${HEX_FILE}
COMMENT "Building ${PROJECT_NAME}.bin and ${PROJECT_NAME}.hex"
# Copy files to a custom build directory
COMMAND ${CMAKE_COMMAND} -E copy ${ELF_FILE} "${ROOT_PROJ}/builds/${CHIP}/${EXE_NAME}.elf"
COMMAND ${CMAKE_COMMAND} -E copy ${HEX_FILE} "${ROOT_PROJ}/builds/${CHIP}/${EXE_NAME}.hex"
COMMAND ${CMAKE_COMMAND} -E copy ${BIN_FILE} "${ROOT_PROJ}/builds/${CHIP}/${EXE_NAME}.bin"
# Display sizes
COMMAND ${SIZE} --format=berkeley ${EXE_NAME}.elf ${EXE_NAME}.hex
COMMENT "Invoking: Cross ARM GNU Print Size"
)
add_custom_target(UPLOAD
${GDB} -iex "target remote tcp:127.0.0.1:3333"
-iex "monitor program ${EXE_NAME}.elf"
-iex "monitor reset init"
-iex "disconnect" -iex "quit ")
When I try to compile I am getting the following errors:
[ 82%] Building C object CMakeFiles/FixtureTACO_STM32F303xC.elf.dir/platforms/stm32f3/Hal/src/stm32f3xx_ll_utils.c.obj
[ 86%] Building ASM object CMakeFiles/FixtureTACO_STM32F303xC.elf.dir/platforms/stm32f3/Startup/startup_stm32f303xc.s.obj
cc: warning: ‘-mcpu=’ is deprecated; use ‘-mtune=’ or ‘-march=’ instead
cc: error: unrecognized command line option ‘-mthumb’; did you mean ‘-mtbm’?
cc: error: unrecognized command line option ‘-mfpu=fpv4-sp-d16’
cc: error: unrecognized command line option ‘-mfloat-abi=hard’
The error occurs ONLY when an assembly file (startup.s in this case) is present in source files and when FPU and FLOAR_ABI flags are present. As you can see, error occurs when startup_stm32f303xc.s is compiled.
I suspect that I am adding those flags in the wrong place but I have no clue where to add them in order to get it works.
Later edit: I already have installed arm 7 compiler on my ubuntu system. I can use it without specifying any path as it is already present in environment variables. I can compile without problems ARM code (from Makefiles) for other targets on machine. My problem is with cmake.
In your line set(TOOLCHAIN_PATH "") you must add a path to compiler. First go to get your free GCC ARM ToolChain. Download for your OS. and then just copy to your favorite location. If you using Linux you can use my path configurations:
1.) Copy gcc arm compirel to /opt/ directory:
sudo tar xjfv ~/Downloads/gcc-arm-none-eabi-7-2018-q2-update-linux.tar.bz2 -C /opt/
For more "sexy" path you can do symbolic link:
sudo ln -s /opt/gcc-arm-none-eabi-7-2018-q2-update/ /opt/gcc-arm-none-eabi
After that go to your CMakeLists.txt and rewrite your set command to:
set(TOOLCHAIN_PATH "/opt/gcc-arm-none-eabi/bin")
But there is better solution to build your project for STM32, but with already done stm32-cmake template project, specifically made for STM32 family. It is mush easier done with something working. You will also need two prerequisites STM32CubeMX installed and again GCC ARM ToolChain. If you want to know how to use this template just DM me and I will you give a quick guidance.
OK, I finally managed to figure it out!
I had to replace
set(AS ${TOOLCHAIN_PATH}arm-none-eabi-as)
with
set(CMAKE_ASM_COMPILER ${TOOLCHAIN_PATH}arm-none-eabi-gcc)
It is not a mistake, it is gcc compiler. You can also append these flags: -x assembler-with-cpp.
CMake didn't know about my custom ASM compiler so it was using default system ASM compiler unless I force it by writing CMAKE_ASM_COMPILER. Now the project is being build and works fine on microcontroller.
The other answers were ok, but had half of the solution. Only ASM filese were compiled with wrong compiler.
I think you try to compile code for ARM using x86 compiler. It will not work. You need to download the ARM toolchain and use the correct compiler.
-mcpu is depreciated in the x86 branch, but is not in the ARM branch
another options just not exist in the x86 compiler.
I have a project whose directory layout looks like:
- src/ #Contains main source code
- ext/ #Contains external libraries and headers from GitHub
- CMakeLists.txt
The problem is that no matter what I do, CMake always seems to pass ext/ to the compiler as a relative path, like this:
/usr/bin/c++ -I../ext mysrc.cpp
I've tried doing both:
include_directories("${PROJECT_SOURCE_DIR}/ext")
include_directories("/home/user/project/ext")
But it doesn't seem to matter. The directory is always passed to -I as ../ext.
Why does this matter? At the end of my build I invoke gcov -r <source file> which tells gcov to generate coverage reports from my source file and any relative paths found within. As a result, gcov is going into ext/ and generating reports for tons of stuff I don't care about and it's taking up a lot of time. If CMake would instead pass in -I/home/user/project/ext then gcov -r would ignore everything in ext/.
As far as I can tell from:
https://cmake.org/cmake/help/v3.13/command/include_directories.html ... this isn't possible, but maybe I'm just missing something?
Edit: This appears to be a problem with specifically the ninja generator. When using the Unix Makefiles generator, everything is passed via absolute paths.
https://gitlab.kitware.com/cmake/cmake/issues/18666
Edit2:
user#antimony:~/cmake_test$ ls
CMakeLists.txt ext src
user#antimony:~/cmake_test$ cat CMakeLists.txt
project(Hello)
add_subdirectory(src)
user#antimony:~/cmake_test$ cat src/CMakeLists.txt
include_directories(
.
${PROJECT_SOURCE_DIR}/ext
)
add_executable(hello_world hello.cpp)
user#antimony:~/cmake_test$ cat src/hello.cpp
#include <useless.h>
int main()
{
hello h;
return 0;
}
user#antimony:~/cmake_test$ cat ext/useless.h
struct hello {
int x;
};
user#antimony:~/cmake_test$ ~/Downloads/cmake-3.13.1-Linux-x86_64/bin/cmake --version
cmake version 3.13.1
CMake suite maintained and supported by Kitware (kitware.com/cmake).
user#antimony:~/cmake_test$ mkdir build && cd build
user#antimony:~/cmake_test/build$ ~/Downloads/cmake-3.13.1-Linux-x86_64/bin/cmake .. -G Ninja
-- The C compiler identification is GNU 7.3.0
-- The CXX compiler identification is GNU 7.3.0
...
-- Build files have been written to: /home/user/cmake_test/build
user#antimony:~/cmake_test/build$ ninja -v
[1/2] /usr/bin/c++ -I../src/. -I../ext -MD -MT src/CMakeFiles/hello_world.dir/hello.o -MF src/CMakeFiles/hello_world.dir/hello.o.d -o src/CMakeFiles/hello_world.dir/hello.o -c ../src/hello.cpp
[2/2] : && /usr/bin/c++ -rdynamic src/CMakeFiles/hello_world.dir/hello.o -o src/hello_world && :
user#antimony:~/cmake_test/build$ cat build.ninja
# CMAKE generated file: DO NOT EDIT!
# Generated by "Ninja" Generator, CMake Version 3.13
# This file contains all the build statements describing the
# compilation DAG.
...
#############################################
# Order-only phony target for hello_world
build cmake_object_order_depends_target_hello_world: phony || src/CMakeFiles/hello_world.dir
build src/CMakeFiles/hello_world.dir/hello.o: CXX_COMPILER__hello_world ../src/hello.cpp || cmake_object_order_depends_target_hello_world
DEP_FILE = src/CMakeFiles/hello_world.dir/hello.o.d
INCLUDES = -I../src/. -I../ext
OBJECT_DIR = src/CMakeFiles/hello_world.dir
OBJECT_FILE_DIR = src/CMakeFiles/hello_world.dir
TARGET_COMPILE_PDB = src/CMakeFiles/hello_world.dir/
TARGET_PDB = src/hello_world.pdb
# =============================================================================
# Link build statements for EXECUTABLE target hello_world
The example shows what may be considered an in-source build. That is when the build directory is the same or a sub-directory of the src folder (not that there is a hard definition or anything, but this does trigger the ninja issue of using relative paths on the command line). Try mkdir ~/cmake_build && cd ~/cmake_build && cmake ~/cmake_test then it should use absolute paths for everything.
Either way there really isn't a specific way to force one or the other. In general cmake generators will use absolute paths for everything that ends up used on the command line. There seems to be issues with Ninja that prevent the generator from using absolute paths for in-source builds (https://github.com/ninja-build/ninja/issues/1251).
The Problem:
So, I'm writing an application in C that uses the glib's hash table function. Unfortunately, because Homebrew installs glib into a subdirectory, pre-written includes are broken, and it completely fails to compile. Part of the problem is related to the tendency glib has to hide itself, but I'm aware of how to solve this, and have written a makefile that works. However, I would still prefer to be able to use my IDE as usual, and this seems like it may cause other problems in the future, so I am wondering whether anybody has any advice.
Below is the makefile, cmakelists.txt and errors.
Please note that my problem is not including CMake, it is due to the fact that Homebrew has installed it to /usr/lib/local/glib-2.0/glib.h, and the header files it includes are under /usr/lib/local/glib-2.0/glib/. Unfortunately, all of glibs header include the others as such
#include <glib/galloca.h>
#include <glib/garray.h>
#include <glib/gasyncqueue.h>
#include <glib/gatomic.h>
#include <glib/[...]>
where these should be
#include <glib-2.0/glib/galloca.h>
#include <glib-2.0/glib/garray.h>
e.t.c, You get the idea
Makefile
# Compiler
CC = gcc
#CFlags
CFlags = -g -Wall -I/usr/local/Cellar/glib/2.46.2/include/glib-2.0 -I/usr/local/Cellar/glib/2.46.2/lib/glib-2.0/include -I/usr/local/opt/gettext/include -L/usr/local/Cellar/glib/2.46.2/lib -L/usr/local/opt/gettext/lib -lglib-2.0 -lintl -D_REENTRANT -I/usr/local/Cellar/gtk+3/3.18.9/include/gtk-3.0 -I/usr/local/Cellar/glib/2.46.2/include/gio-unix-2.0/ -I/usr/local/Cellar/cairo/1.14.6_1/include/cairo -I/usr/local/Cellar/libepoxy/1.3.1/include -I/usr/local/Cellar/pango/1.38.1/include/pango-1.0 -I/usr/local/Cellar/harfbuzz/1.2.4/include/harfbuzz -I/usr/local/Cellar/pango/1.38.1/include/pango-1.0 -I/usr/local/Cellar/atk/2.18.0_1/include/atk-1.0 -I/usr/local/Cellar/cairo/1.14.6_1/include/cairo -I/usr/local/Cellar/pixman/0.34.0/include/pixman-1 -I/usr/local/Cellar/fontconfig/2.11.1_2/include -I/usr/local/Cellar/freetype/2.6.3/include/freetype2 -I/usr/local/Cellar/libpng/1.6.21/include/libpng16 -I/usr/local/Cellar/gdk-pixbuf/2.32.3/include/gdk-pixbuf-2.0 -I/usr/local/Cellar/libpng/1.6.21/include/libpng16 -I/usr/local/Cellar/glib/2.46.2/include/glib-2.0 -I/usr/local/Cellar/glib/2.46.2/lib/glib-2.0/include -I/usr/local/opt/gettext/include
TARGET = main
all: $(TARGET)
$(TARGET): $(TARGET).c
$(CC) $(CFlags) -o $(TARGET) $(TARGET).c
clean:
$(RM) $(TARGET)
Compile Errors
/Applications/CLion.app/Contents/bin/cmake/bin/cmake --build /Users/ennis/Library/Caches/CLion12/cmake/generated/85d4a0ab/85d4a0ab/Debug --target all -- -j 4
[ 50%] Building C object CMakeFiles/TaskAppBuilder_C.dir/main.c.o
In file included from /Users/ennis/TaskAppBuilder-C/main.c:4:
In file included from /Users/ennis/TaskAppBuilder-C/main.h:15:
In file included from /Users/ennis/TaskAppBuilder-C/glib.h:30:
/usr/local/include/glib-2.0/glib.h/galloc.h:32:10: fatal error: 'galloc.h' file not found
#include <galloc.h>
^
1 error generated.
make[2]: *** [CMakeFiles/TaskAppBuilder_C.dir/main.c.o] Error 1
make[1]: *** [CMakeFiles/TaskAppBuilder_C.dir/all] Error 2
make: *** [all] Error 2
CMakeLists.txt
cmake_minimum_required(VERSION 3.3)
project(TaskAppBuilder_C)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c11")
set(SOURCE_FILES main.c main.h)
add_executable(TaskAppBuilder_C ${SOURCE_FILES} main.c main.h)