For example, if I need Gtk+ include paths.
How to use pkg-config gtk+-2.0 --cflags in Xcode project settings?
One option, but it's not very portable to other developers on the project -- you can just run pkg-config gtk+-2.0 --cflags in your Terminal and paste it into Build Settings -> Other C Flags. I'd be interested to hear how others deal with this in a more portable way though. Ideally, it would be nice to have pkg-config run at compile-time to make building more system-independent.
Create an aggregate target
In Build Phases, add a Run Script
#!/bin/bash
OTHER_CPLUSPLUSFLAGS="$(pkg-config gtk+-2.0 --cflags)"
echo -e "OTHER_CPLUSPLUSFLAGS = \$(inherited) ${OTHER_CPLUSPLUSFLAGS}" > MyApp.xcconfig
In Info in your project, set MyApp.xcconfig as your target configuration file
In Build Phases in your app target, add the aggregate target as a dependency
Exclude MyApp.xcconfig in your version control
One drawback is that until you build the aggregate target directly or indirectly at least once, the autocomplete will not work properly.
More portable would be to write a script that writes the output of pkg-config into an .xcconfig file and then include that in your project. Just be sure to not add it into your source repository.
Use a makefile that uses pkg-config and any other shell tools to build a lib.
Create a small, dependency-free API file for the lib that will compile in XCode, and include it and the built lib in the XCode build.
Optional: encapsulate the makefile build into a "Run Script" build step in XCode.
In addition to #keithyip's great answer, if linker flags are also needed, use
OTHER_LDFLAGS:
#!/bin/sh
OTHER_CPLUSPLUSFLAGS=$(pkg-config --cflags gtk+-2.0)
OTHER_LDFLAGS=$(pkg-config --libs gtk+-2.0)
echo "OTHER_CPLUSPLUSFLAGS = \$(inherited) ${OTHER_CPLUSPLUSFLAGS}" > MyApp.xcconfig
echo "OTHER_LDFLAGS = \$(inherited) ${OTHER_LDFLAGS}" >> MyApp.xcconfig
Related
I try to use the c++ language bindings for the ev3dev lego brick: https://github.com/ddemidov/ev3dev-lang-cpp
The instruction is as follows:
mkdir build
cd build
cmake .. -DEV3DEV_PLATFORM=EV3
make
I am running windows and have cmake and mingw available. After running cmake it creates some files in the build directory. However: There is no makefile which could be picked of by make. So I am wondering how iam supposed to compile these bindings
On Windows, CMake generates a MSVC solution by default. Check for a .sln file in your build directory.
The instructions you linked are assuming a Unix-ish platform, where the default is to create Makefiles.
If you actually want Makefiles on Windows, add -G "Unix Makefiles" to the cmake line.
If you want to use MSVC as compiler but work on the command line, another option is -G "NMake Makefiles", and calling nmake after that.
Make sure to delete your build directory before trying to build a new generator target. CMake can be touchy about that.
Check cmake --help for a list of available options. (Especially the generator targets are platform-specific.)
Is there a way to configure CLion to use a local makefile to compile code, rather than CMake? I can't seem to find the way to do it from the build options.
Update: If you are using CLion 2020.2, then it already supports Makefiles. If you are using an older version, read on.
Even though currently only CMake is supported, you can instruct CMake to call make with your custom Makefile. Edit your CMakeLists.txt adding one of these two commands:
add_custom_target
add_custom_command
When you tell CLion to run your program, it will try to find an executable with the same name of the target in the directory pointed by PROJECT_BINARY_DIR. So as long as your make generates the file where CLion expects, there will be no problem.
Here is a working example:
Tell CLion to pass its $(PROJECT_BINARY_DIR) to make
This is the sample CMakeLists.txt:
cmake_minimum_required(VERSION 2.8.4)
project(mytest)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
add_custom_target(mytest COMMAND make -C ${mytest_SOURCE_DIR}
CLION_EXE_DIR=${PROJECT_BINARY_DIR})
Tell make to generate the executable in CLion's directory
This is the sample Makefile:
all:
echo Compiling $(CLION_EXE_DIR)/$# ...
g++ mytest.cpp -o $(CLION_EXE_DIR)/mytest
That is all, you may also want to change your program's working directory so it executes as it is when you run make from inside your directory. For this edit: Run -> Edit Configurations ... -> mytest -> Working directory
While this is one of the most voted feature requests, there is one plugin available, by Victor Kropp, that adds support to makefiles:
Makefile support plugin for IntelliJ IDEA
Install
You can install directly from the official repository:
Settings > Plugins > search for makefile > Search in repositories > Install > Restart
Use
There are at least three different ways to run:
Right click on a makefile and select Run
Have the makefile open in the editor, put the cursor over one target (anywhere on the line), hit alt + enter, then select make target
Hit ctrl/cmd + shift + F10 on a target (although this one didn't work for me on a mac).
It opens a pane named Run target with the output.
Newest version has better support literally for any generated Makefiles, through the compiledb
Three steps:
install compiledb
pip install compiledb
run a dry make
compiledb -n make
(do the autogen, configure if needed)
there will be a compile_commands.json file generated
open the project and you will see CLion will load info from the json file.
If you your CLion still try to find CMakeLists.txt and cannot read compile_commands.json, try to remove the entire folder, re-download the source files, and redo step 1,2,3
Orignal post: Working with Makefiles in CLion using Compilation DB
To totally avoid using CMAKE, you can simply:
Build your project as you normally with Make through the terminal.
Change your CLion configurations, go to (in top bar) :
Run -> Edit Configurations -> yourProjectFolder
Change the Executable to the one generated with Make
Change the Working directory to the folder holding your executable (if needed)
Remove the Build task in the Before launch:Activate tool window box
And you're all set! You can now use the debug button after your manual build.
Currently, only CMake is supported by CLion. Others build systems will be added in the future, but currently, you can only use CMake.
An importer tool has been implemented to help you to use CMake.
Edit:
Source : http://blog.jetbrains.com/clion/2014/09/clion-answers-frequently-asked-questions/
I am not very familiar with CMake and could not use Mondkin's solution directly.
Here is what I came up with in my CMakeLists.txt using the latest version of CLion (1.2.4) and MinGW on Windows (I guess you will just need to replace all:
g++ mytest.cpp -o bin/mytest by make if you are not using the same setup):
cmake_minimum_required(VERSION 3.3)
project(mytest)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
add_custom_target(mytest ALL COMMAND mingw32-make WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR})
And the custom Makefile is like this (it is located at the root of my project and generates the executable in a bin directory):
all:
g++ mytest.cpp -o bin/mytest
I am able to build the executable and errors in the log window are clickable.
Hints in the IDE are quite limited through, which is a big limitation compared to pure CMake projects...
I am moving away from simply using a Makefile and text editor. I would like to convert my Makefile so that I can use XCode properly. How can I convert this Makefile?
all:
gcc engine.c $(MRUBY_HOME)/build/host/lib/libmruby.a -I $(MRUBY_HOME)/include $(shell pkg-config --cflags --libs sdl2)
there is nothing stopping you from using a makefile in Xcode. just setup your target as an external build system and populate the "Build Tool" setting with the path to make (/usr/bin/make) and the "Directory" field pointing to the directory in your project containing the makefile. you can populate the "Arguments" field with any arguments needed for your makefile; these can be done with Xcode variables such as $(ACTION) (build, clean) and $(CONFIGURATION) (debug, release).
If you want to do away with the makefile completely then you will need to first add the source files and libraries to your target under the "build phases" tab for your build target. Any shell scripts can be added as a new "run script" build phase. other settings can be set from the "build settings" tab; specifically the "other c flags" field, although most compiler and linker settings should appear as options in that section.
I have compiled gdc together with gcc using the android build-gcc.sh script, and have included a new stub in build/core/definitions.mk to deal with D language files as a part of the build process. I know things are compiling OK at this point, but my problem is linking:
When I build a project, I get this error:
ld: crtbegin_so.o: No such file: No such file or directory
This is true for regular c-only projects as well. Now I ran a quick find in my build directory, and found that the file (crtbegin_so.o) does exist within the sysroot I specified when I compiled gcc (or rather, when build-gcc.sh built it).
What are some things I could look for to find a solution to this problem?
Would copying the files locally and linking directly to them be a decent solution in the
interim?
Why would ld (or collect2) be trying to include these for a gdc (D Language) linkage?
The issue arises on NDK r7c for linux as well.
I found that the toolchain ignores the platform location ($NDK_ROOT/platforms/android-8/arch-arm/usr/lib/) and searches for it in the toolchain path, which is incorrect.
However, as the toolchain also searches for the file in the current directory, one solution is to symlink the correct platform crtbegin_so.o and crtend_so.o into the source directory:
cd src && ln -s NDK_ROOT/platforms/android-8/arch-arm/usr/lib/crtbegin_so.a
cd src && ln -s NDK_ROOT/platforms/android-8/arch-arm/usr/lib/crtend_so.a
Thus your second point should work out (where you can do a symlink, instead of a copy)
NOTE 1:This assumes that the code is being compiled for API8 (Android 2.2) using the NDK. Please alter the path to the correct path as per your requirement.
NOTE 2:Configure flags used:
./configure \
--host=arm-linux-androideabi \
CC=arm-linux-androideabi-gcc \
CPPFLAGS="-I$NDK_ROOT/platforms/android-8/arch-arm/usr/include/" \
CFLAGS="-nostdlib" \
LDFLAGS="-Wl,-rpath-link=$NDK_ROOT/platforms/android-8/arch-arm/usr/lib/ -L$NDK_ROOT/platforms/android-8/arch-arm/usr/lib/" \
LIBS="-lc"
I have found that adding --sysroot=$(SYSROOT) to the compiler options fixes the error:
cannot open crtbegin_so.o: No such file or directory
from my makefile...
CC= $(CROSS_COMPILE)gcc -fvisibility-hidded $(INC) $(LIB) -shared
Note: this assumes that the setenv-android.sh has been run to setup the environment
$. ./setenv-android.sh
In my case quotes were missing from sysroot path.
When I changed
--sysroot=${ANDROID_NDK}\platforms\android-17\arch-arm
to
--sysroot="${ANDROID_NDK}\platforms\android-17\arch-arm"
the project was compiled and linked successfully.
I faced with the same issue in two separate cases:
during building boost for android
during using android-cmake project.
Once I have switched to standalone toolchain issue gone, here is example of command which prepare standalone toolchain
$NDK_ROOT/build/tools/make-standalone-toolchain.sh --platform=android-9 --install-dir=android-toolchain --ndk-dir=$NDK_ROOT --system=darwin-x86_64 --toolchain=arm-linux-androideabi-4.9
Boost specific
for boost you need specify --sysroot several times in your jam
<compileflags>--sysroot=$NDK_ROOT/platforms/android-9/arch-arm
<linkflags>--sysroot=$NDK_ROOT/platforms/android-9/arch-arm
I've set LIBRARY_SEARCH_PATHS to /opt/local/lib, and verified that the library in question is there (I'm linking to GLEW):
$ls /opt/local/lib
libGLEW.1.5.1.dylib libfreetype.a libz.a
libGLEW.1.5.dylib libfreetype.dylib libz.dylib
libGLEW.a libfreetype.la pkgconfig
libGLEW.dylib libz.1.2.3.dylib
libfreetype.6.dylib libz.1.dylib
but Xcode gives me the linker error
library not found for -lGLEW
I'm generating the Xcode project with CMake, so I don't want to explicitly modify the Xcode project (if someone suggests adding it as a framework, or something like that). Xcode recognizes USER_HEADER_SEARCH_PATHS fine (as in this question); why doesn't it work here?
Perhaps adding something like this to your CMakeLists.txt?
find_library(GLEW_LIB GLEW /opt/local/lib)
if(NOT ${GLEW_LIB})
message(FATAL_ERROR "Could not find GLEW")
endif()
target_link_libraries(myprogram ${GLEW_LIB} ...)
Where myprogram is the name of the target executable that needs to link with the library. You would replace the ... with the other libraries you are using on that executable.
This way CMake would handle the library path details for you.
Xcode works on potentially multiple SDK's, so whenever your define these kinds of things (like HEADER_SEARCH_PATHS or LIBRARY_SEARCH_PATHS) the current SDK root is prepended to the actual path that's getting passed to the linker.
So, one way to make this work would be to add your directory to the SDK. For example, assuming you're building with the Mac OS X 10.5 sdk, you could add your opt dir:
ln -s /opt /Developer/SDKs/MacOSX10.5.sdk/opt
Your library would now be found on your system.
If you don't want to do this, then you will have to look at CMake and find out how to get it to generate a library requirement for your actual library (I don't know anything about CMake, so I can't help you there). This is also why you see a difference between USER_HEADER_SEARCH_PATHS and HEADER_SEARCH_PATHS re your other question.
As another option, you could also specify this path with the OTHER_LDFLAGS build variable:
OTHER_LDFLAGS=-L/opt/local/lib
This would cause the linker to search /opt/local/lib as well as its standard paths and wouldn't require you to generate a different project file.