As a follow up to another question I recently asked, I realize my issue is that I don't know how to include Apple 'frameworks' in the Eclipse CDT project properties so that they're picked up and linked at compile time.
This results in includes in this form not to be resolved:
#include <OpenCL/cl.h>
Where the actual path would be something like:
/System/Library/Frameworks/OpenCL.framework/Versions/A/Headers
And the cmd line option would be (if I was manually compiling):
-framework OpenCL
In summary: How can I get Eclipse to see the framework(s) I want fromt he project properties?
Any help highly appreciated!
An alternative answer to JohnIdol's answer. In particular, an approach that can work in the case that you don't want to change the <OpenCL/cl.h> reference to <cl.h>
First, I came to the site with exactly this question in mind (how to include Apple 'frameworks' in Eclipse CDT (C/C++) projects) and I really appreciate the discussion - it gave me a starting point.
John's answer is cool but it does involve changing how the include file is called (e.g., <OpenCL/cl.h> becomes <cl.h> in the code). Then he does a direct include-path reference in the eclipse properties for each Header directory he needs.
In my case, I had checked-out GNU Backgammon to play around with the source code. This code compiles (with some mods to LDFLAGS and CPPFLAGS before doing the autogen.sh) on the OS X CLI environment using the I-guess-standard apple approach of the -framework option and with include files references like
#include <CoreAudio/CoreAudioTypes.h>
I may never actually commit anything but I didn't want to start hacking the #includes in code that is already compiling just fine using the standard approach. So I did the following:
Made a new directory in my workspace gnubg called "Frameworks".
Inside that directory, make soft-links to the header directories.
ln -s /System/Library/Frameworks/CoreAudio.framework/Headers CoreAudio
In the gnubg project properties > C/C++ General> Paths and Symbols, added /gnubg/Frameworks to the Include directories (as a workspace path). I only had to do this once, regardless of the number of soft links I made.
This way I did not have to change the code at all, Eclipse was happy, CLI compilation was happy as well.
I note that there is a slight wrinkle if using some directories in Frameworks such as the CoreServices.framework. In those cases there is a Frameworks subdirectory and relative path references in some of the include files (e.g., ..) to other include files. So in this case I had to modify the procedure a bit. Basically, I had to add an additional sub-directory in Frameworks for CoreServices.framework and then in that directory I had to add two soft links. One for the CoreServices (for the Headers) and one for Framework subdirectory.
lrwxr-xr-x 1 dhansen staff 57B Jul 27 02:06 CoreServices -> /System/Library/Frameworks/CoreServices.framework/Headers
lrwxr-xr-x 1 dhansen staff 60B Jul 27 02:05 Frameworks -> /System/Library/Frameworks/CoreServices.framework/Frameworks
Then I had to add /gnubg/Frameworks/CoreServices.framework to the include path (step 3 above).
And that's it. No more include file problems.
Since current Eclipse CDT releases don't perform sub-framework header inclusion correctly, you can avoid sub-framework problems (like those generated by the CoreServices header files) by creating symbolic links to the include directories of each sub-framework. I elaborated on this subject, which stems from danhan answer, in the following post:
http://thegreyblog.blogspot.com/2014/02/how-to-include-apple-frameworks-headers.html
In order to automate this process, I've created a Z shell script which automates this process and creates the symlink to the specified frameworks' header directory, together with the links to the include directory of each one of their sub-frameworks. The script can be found here: https://github.com/emcrisostomo/link-osx-framework-headers
Hope this helps.
OK so I had to include like this:
#include <cl.h>
Then add an include to the folder with the header file in Properties > C/C++ General > Paths and Symbols resulting in the following option for the compiler:
-I/System/Library/Frameworks/OpenCL.framework/Versions/A/Headers
And, most notably, had to add the following options for libraries path and framework inclusion under Properties > C/C++ Build > Settings:
-L/System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries -framework OpenCL
The above did the trick.
goto Your Project>Properties>MacOS X C++ Linker>Command
Where "g++" add " -framework OpenCL"
Related
I used to work with VSCode C/C++ extension. there was a feature in this extension(in a json file), called "includePath", which I could set the paths for my headers, so without execution of CMake or make, I would have the suggestion of my headers and code completion from those.
now I have switched to neovim and clangd as the language server for code completion. I searched a lot to find the corresponding feature in clangd options but I could not find anything more than this link.
since the clangd is a powerful language server, I am in wonder if there is not such a feature in it. so I want to know is there actually such a feature in clangd? and if YES how can I use that?
Note: I use a language client, called "coc-clangd". I don't know if it matters or not.
Clangd uses compile_commands.json database file which contains flags (such as include directories) for each file in project. But this file is auto-generated, so all modifications to it will be overwritten eventually. You can ask CMake to add any custom compile flags with -DCMAKE_CXX_FLAGS command line argument.
Example for system headers (#include <file.h>):
cmake -DCMAKE_CXX_FLAGS="-isystem /path/to/includes" /path/to/source
For project headers (#include "file.h"):
cmake -DCMAKE_CXX_FLAGS=-Ipath/to/includes /path/to/source
Additionally, you can set CXXFLAGS environment variable:
export CXXFLAGS="-isystem /path/to/includes"
cmake path/to/sources
After that new flags should appear in your compile_commands.json file.
Maybe this is useful: https://clangd.llvm.org/config
Create a file called '.clangd' in the top-level of the source directory.
Add those content.
CompileFlags: # Tweak the parse settings
Add:
- "-I=[folder]"
But I think this is not recommend, all include directories should be add in CMakeLists.txt file.
You can add includePath to clangd.fallbackFlags into vscode's settings.json like this:
"clangd.fallbackFlags": [
"-I${workspaceFolder}/include",
"-I/my/include"
]
To use code completion provided by Clangd, let Clangd retrieve include paths from compiler_commands.json with compiler calls used by CMake. Set the CMAKE_EXPORT_COMPILE_COMMANDS option in CMakeLists.txt, it will output compiler_commands.json to the build directory when CMake is run:
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
Copy the generated compiler_commands.json to the project source directory. Clangd will now source this file.
I'm currently working to upgrade a set of c++ binaries that each use their own set of Makefiles to something more modern based off of Autotools. However I can't figure out how to include a third party library (eg. the Oracle Instant Client) into the build/packaging process.
Is this something really simple that I've missed?
Edit to add more detail
My current build environment looks like the following:
/src
/lib
/libfoo
... source and header files
Makefile
/oci #Oracle Instant Client
... header and shared libraries
Makefile
/bin
/bar
... source and header files
Makefile
Makefile
/build
/bin
/lib
build.sh
Today the top level build.sh does the following steps:
Runs each lib's Makefile and copies the output to /build/lib
Runs each binary's Makefile and copied the output to /build/bin
Each Makefile has a set of hardcoded paths to the various sibling directories. Needless to say this has become a nightmare to maintain. I have started testing out autotools but where I am stuck is figuring out the equivalent to copying /src/lib/oci/*.so to /build/lib for compile time linking and bundling into a distribution.
I figured out how to make this happen.
First I switched to a non recursive make.
Next I made the following changes to configure.am as per this page http://www.openismus.com/documents/linux/using_libraries/using_libraries
AC_ARG_WITH([oci-include-path],
[AS_HELP_STRING([--with-oci-include-path],
[location of the oci headers, defaults to lib/oci])],
[OCI_CFLAGS="-$withval"],
[OCI_CFLAGS="-Ilib/oci"])
AC_SUBST([OCI_CFLAGS])
AC_ARG_WITH([oci-lib-path],
[AS_HELP_STRING([--with-oci-lib-path],
[location of the oci libraries, defaults to lib/oci])],
[OCI_LIBS="-L$withval -lclntsh -lnnz11"],
[OCI_LIBS='-L./lib/oci -lclntsh -lnnz11'])
AC_SUBST([OCI_LIBS])
In the Makefile.am you then use the following lines (assuming a binary named foo)
foo_CPPFLAGS = $(OCI_CFLAGS)
foo_LDADD = libnavycommon.la $(OCI_LIBS)
ocidir = $(libdir)
oci_DATA = lib/oci/libclntsh.so.11.1 \
lib/oci/libnnz11.so \
lib/oci/libocci.so.11.1 \
lib/oci/libociicus.so \
lib/oci/libocijdbc11.so
The autotools are not a package management system, and attempting to put that type of functionality in is a bad idea. Rather than incorporating the third party library into your distribution, you should simply have the configure script check for its existence and abort if the required library is not available. The onus is on the user to satisfy the dependency. You can then release a binary package that will allow the user to use the package management system to simplify dependency resolution.
I have been struggling with this for quite a while, and my adventures with cmake have only resulted in hackish solutions that I am pretty sure are not correct.
I created a library that consists of several files, as follows:
-libfolder
-codepart1folder
-CMakeLists.txt
-codepart1.cpp
-codepart1.hpp
-codepart2folder
-codepart3folder
-lib.cpp
-lib.hpp
-CMakeLists.txt
I wrote a CMakeLists file to compile the library (after some experimentation), and I can generate a lib.a file. Now I would like to include this code as a library in other projects, and access it through the interface in lib.hpp. What is the best way to do this, in terms of directory structure, and what I need to put into CMakeLists.txt in my root project?
My current attempt has been to add -libfolder as a subfolder to my current project, and add the commands:
include_directories(${PROJECT_SOURCE_DIR}/libfolder)
link_directories(${PROJECT_BINARY_DIR}/libfolder)
add_subdirectory(libfolder)
target_link_libraries(project lib)
When I run make, the library compiles fine, but when project.cpp compiles, it complains that it cannot find codepart1.hpp (which is included in lib.hpp, included from project.cpp).
I suspect that this is the wrong way about doing this, but I cannot wade through the CMake documentation and find a good tutorial on setting up projects like this. Please help, CMake gurus!
The clean way to import one CMake project into another is via the find_package command. The package declaration is done by using the export command. An advantage of using find_package is that it eliminates the need to hard-code paths to the package's files.
Regarding the missing hpp file, you didn't include codepart1folder, so it's not on the include path.
Ok, so after consulting a coworker of mine who is a CMake guru, it seems CMake does not have support for what I am trying to do, leaving one with 3 options:
Add all of the dependencies to the parent projects CMakeLists.txt - not very clean, but it will get the thing to work. You'll have to do this for every project you add the code to, and go back and fix things if your library changes.
clean up your library headers. This is done through some compiler hackery. The idea is to forward-declare every class, and use only pointers or boost::shared_ptr, and then include the dependencies only in the cpp file. That way you can build the cpp file using all the findpackage stuff, and you get the bonus of being able to use the lib by only including the header and linking to the library.
Look into build systems. Having portable code and fast code compilation with complex dependencies is not a solved problem! From my investigations it turned out to be quite complicated. I ended up adopting my coworkers build system which he created himself in cmake, using things he picked up from Google.
Looking at your post you don't seem to add 'codepart1folder' to the includes anywhere. How are you including codepart1.hpp as:
#include <codepart1.hpp>
#include "codepart1folder/codepart1.hpp"
I don't think there is a standard accepted way to structure cmake projects. I've looked at a bunch of cmake repos and they tend to have differences. Personally I do the following:
-project
CMakeLists.txt
-build
-cmake
OptionalCmakeModule.cmake
-src
-Main
Main.cpp
Main.hpp
-DataStructs
SomeTree.hpp
SomeObject.hpp
-Debug
Debug.hpp
-UI
Window.hpp
Window.cpp
Basically that dumps all the source code into 1 directory, then you perform an out of source build with: 'mkdir build && cd build && cmake .. && make' in the projects root folder.
If you have separate libs as part of your project, then you might want a separate libs directory with another subfolder for your specific lib.
I have some of my repos on: https://github.com/dcbishop/ if you want to look at the CMakeLists.txt files.
The main problems with my project structure are that I use the FILE_GLOB which is apparently the 'wrong' way to do things (if you add files after running 'cmake ..' then they won't be picked up hen you do a 'make'). I haven't figured out what the 'right' way to do it is (from what I can see it involves keeping a separate list of files) I also only use 1 CMakeLists.txt file.
Some projects also choose to separate their cpp and hpp files into separate directories. So you would have an include and src folders (at least for the hpp files that are intended to be used externally). I think that would mainly be for projects that are mainly large libraries. Would also make installing header files much easier.
You are probably missing
include_directories(${PROJECT_SOURCE_DIR}/libfolder/codepart1folder)
In such a case you might want to set( CMAKE_INCLUDE_CURRENT_DIR on) to add all folders to the include directory path variable.
Check cmake's output on the command line whether the correct include folders are set or not. Additionally you can always use message() as "print debugging" for cmake variables.
In case of include directories however you need to read the directory property to see what is actually in the include directories.
get_property(inc_dirs DIRECTORY PROPERTY INCLUDE_DIRECTORIES)
message("inc_dirs = ${inc_dirs}")
I hope this helps you figuring out what is missing.
Edit
I just saw your comment about added codepart1folder in the libfolder. It is only available in the libfolder's include_directory path and not propagated to the root folder.
Since the include codepart1.hpp is present in the lib.hpp however you need to have it also available in the project path otherwise you will get missing declaration errors when you build your project.
I want to integrate a header-only C++ library in my Autotools project. Since the library uses Autoconf and Automake, I use AC_CONFIG_SUBDIRS in configure.ac and added the library dir to the SUBDIRS = line in Makefile.am.
My question is: how do I prevent the header library from being installed by make install? I'm building a single binary, so my users don't need these headers.
I'd prefer not to tamper with the library, so I can fetch upgrade by just untarring the new version.
Here is an idea.
Move all the third-party libraries you do not want to see installed into a subdirectory called noinst/. So for instance if you want to ship your project with something like Boost, unpack it into the directory noinst/boost/. Use AC_CONFIG_SUBDIRS([noinst/boost]). Inside noinst/Makefile.am, do something like this:
SUBDIRS = boost
# Override Automake's installation targets with the command ":" that does nothing.
install:; #:
install-exec:; #:
install-data:; #:
uninstall:; #:
The effect is that whenever some of the recursive "make install*" or "make uninstall" commands are run from the top-level directory, the recursion will stop in noinst/ and not visit its subdirectories. Other recursive commands (like "make", "make clean" or "make dist") will still recurse into the subdirectories.
You could of course override install: and friends directly into the third-party package, and avoid the extra noinst/ directory. But if you are like me, you don't want to tamper with third-party packages to ease their update.
Also a nice property of the above setup is that if someone goes into noinst/boost/ and decide to run make install, it will work. It just does not occur by default when they install your package.
just came across a similar problem and found the solution in the automake manual:
noinst_HEADERS would be the right variable to use in a directory containing only headers and no associated library or program
Andreas
Don't use SUBDIRS then. The following hack may work:
all-local:
${MAKE} -C thatlib all
Of course it would be best if the library remained in its own directory outside of your project, and you just point to it via CFLAGS/LIBS flags.
Is it possible to add include paths and libraries to all C/C++ projects? In others words: How can I make them global or copy one C/C++ project build setting to another one?
For Eclipse Indigo:
There is no possibility to define globally include paths and libraries.
But you can export and import them from one project to another.
Go to Project > Properties > C/C++ General > Paths and Symbols
Then click Export Settings... to save the include paths and/or symbol definitions to a file. In your other project, you can then use Import Settings...
Yes, you can, in 2 steps, more user-friendly as the one mentioned by parvus. Both are done in "Project Properties" -> "C/C++ General" -> "Paths and Symbols":
In an existing project where you've already configured the include paths: Highlight the include paths (in the tab "Includes") which you want to copy to the new project and choose "Export". Note that this adds an [Exp] tag to each line.
In the new created project: In the "References" tab, tick the checkbox of the just mentioned project and when you switch back to the "Includes" tab, you see that all the paths you've just exported appear there.
Referencing the libraries works the same way.
Also have a look at:
the Eclipse Juno Documentation to this topic,
a related StackOverflow question
I often use the CPATH environment variable to include different directories across all my projects. It's found under: c/c++->build->environment.
Be sure to separate each path with a ':' character (not a ';' semicolon).
You can also use PATH to include static libs. However, for me it's only worked reliably in linux. In OSX it ruins make.
The alternative would be to add these libraries and headers to your environments default search paths; place likes /usr/local/lib. Read up on where your linker searches by default.
For libraries I do the following in the source project:
Project -> properties -> c/c++Build -> c++ linker -> libraries
After this I select libraries (shift + mouse) & copy (ctrl + c)
In the blank project:
Project -> properties -> c/c++Build -> c++ linker -> libraries
ctrl + v (paste)
Works fine with eclipse juno
I just copy one project from using eclipse built in Project explorer. Afterwards, just rename source files.
I am looking into it long ago.
A few posts mentioned one method:
Project > Properties > C/C++ General > Paths and Symbols Then click Export Settings..
But it only works for including header files.
To specify libraries and library paths, as far as I know, I do not find an easy solution.
For example, I am now using ffmpeg libraries.
If you use "Makefile", the including and library files can be expressed below:
FFMPEG_LIBS= libavdevice
libavformat
libavfilter
libavcodec
libswresample
libswscale
libavutil
CFLAGS := $(shell pkg-config --cflags $(FFMPEG_LIBS)) $(CFLAGS) LDLIBS
:= $(shell pkg-config --libs $(FFMPEG_LIBS)) $(LDLIBS)
There are many files here.
If I include them one by one in an Eclipse C++ project, it is daunting.
I do not know why there is no option in Eclipse that we could include library files by using past a long line using ; as a separator, such as:
-lavdevice -lavfilter -lswresample -lswscale -lavformat -lavcodec -ldl -lasound -lSDL -lz -lrt -lavutil -lm
Is there any such way, or I have to type the library files one by one, or have to use Makefile?
I faced the same problem and solved it like this :
I saw that in the auto-generated makefile there are lines:
-include ../makefile.init
...
-include ../makefile.defs
...
-include ../makefile.targets
after reading How can I parameterize an Eclipse generated make file I realized that you can define variables outside of you project. That mean it can be shared variable to several projects. So I added makefile.defs file outside of the project and declare in it some variables:
MY_INCLUDE = <path to include>...
MY_LIBS_PATH = <path to libs>...
MY_LIBS = -lmylib ... (the libs)
than in all my projects "properties->c/c++ build->build variables" I defined new variable:
my_include = $(MY_INCLUDE)
my_libs_path = $(MYLIBS_PATH)
my_libs = $(MY_LIBS)
And than you can you those variables in the projects. Go to properties->c/c++ build->Settings and choose compiler includes and add $(my_include). Go to linker and choose Libraries and add to search path $(my_libs_path). For some reason the Libraries (-l) can't take my defined env variable so I bypass it by choosing linker and than go to Miscellaneous and add to linker flags $(my_libs). Finally you have to change the order in the command line (when the linker execute) cause the list of libs need to come after the .o files. So to do that you go to linker and tab and there you can see the final command line that is going to be executed. In "expert settings command line pattern" you move the ${FLAGS} to the back of the command line (that moves the $(my_libs) string to be in the back of the command line). THAT ALL. its a lot but you need to do it only once... hope that it helps someone...
Semi-automagically, it can be done using this perl script:
#!/usr/bin/perl
# pipe the (gcc) compile command into this script
# It emits listOptionValue lines to paste into .cproject
#
# To easily find the paste location, set the include path as usual to a string
# that is easily recognizable in the .cproject, e.g. to "MARKER_INCLUDE_PATH".
#
# Make sure eclipse is not running while you do these sorts of hacks and backup
# your .cproject before.
# -----------------------------------------------------------------------------------------
# sample line: <listOptionValue builtIn="false" value="/usr/include/gdk-pixbuf-2.0"/>
while (<>) {
#include_options = m#-I *(.*?) #g;
print join ("\n", #include_options) . "\n";
print join ('"/>' ."\n" . ' <listOptionValue builtIn="false" value="', #include_options);
print '"/>' . "\n";
}