I'm using Eclipse CDT Neon Release 4.6.2 on Ubuntu 16.04. I work with project where I need to include and link OpenCV 3.1 libraries. For each individual project, I always go to Window > Preferences > C/C++ Build > Settings and add the paths and names of the relevant OpenCV libraries under "Cross G++ Compiler > Includes" and "Cross G++ Linker > Libraries".
Is there a way to avoid doing this for every new project, e.g. through a configuration file for the required libraries which I can simply copy for every project? Entering the same information each time, especially the names of the libraries, is very time consuming.
You could use Makefile projects rather than Managed Build projects (in the New C++ Project dialog, select "Makefile project" as the project type instead of "Executable"/"Shared Library"/etc.).
You would then have to write a makefile that specifies what compiler commands to run to build the project, including the flags for OpenCV's include path and library path.
Once you write the makefile once, you can reuse most of it for different projects, either by copy-and-paste, or by factoring out the reusable bits into a shared makefile that you include from the projects' makefiles.
I switched to using Makefile projects exactly for this reason.
Related
I try to compile an eclipse-project written in c++ which is building a .so-File. Now i try to build the project without an IDE. I tried it with MinGW but the created .so doesn't work. I think there are used some special packages but how can I get the information's.
Is there a way to Export the build settings and import them into MinGW?
How can i else set the compiler?
This is the ToolChainEditor which i would recreat in MinGW.
You can't import a configuration into mingw, but you can tell mingw where to find a configuration of sorts.
Eclipse can be configured to generate a makefile (At least as recent as Neon). Select your project and use the main menu to navigate Project->Properties->C/C++ Build->Tool Chain Editor. Set the "Current builder" to Gnu Make Builder and build the project.
In the generated folder where you would find the finished executable you will find three more files: makefile, objects.mk and sources.mk and can use the make utility that often comes with mingw. It can also be downloaded separately if you have to.
From the command line, enter the folder and type make. Magic will happen. If you want to know more about the magic, make is a very deep topic well worth learning, even if only as a gateway drug to more modern build systems that descended from it.
I'm currently trying to use the Dlib c++ library in my own project. So I included the main folder of dlib to my project. I also added the dlib/all/source.cpp to my project. When I try to compile the code of the svm_c_ex.cpp example in my own test.cpp file, I only get:
fatal error: dlib/svm.h: No such file or directory
The section Dlib: How to compile didn't help me and I couldn't find further information online. Any help is appreciated!
You need to compile the DLib library first, using the instructions from the website.
cd examples
mkdir build
cd build
cmake ..
cmake --build . --config Release
cmake is a famous tool to build software on multiple platforms. It generates required files first and then you can compile the library using those generated files later.
You need to add the "include" directories (the folders where the headers exist) in your project configuration. I'm quite not sure of where exactly to add in Eclipse CDT.
After that, your program gives linker error because the the header files only contain skeletons of your library code. Actual implementation need to be linked with "linker options" in project properties. You need to add your library's .lib/.a files with your program. I don't exactly remember where is linker options in CDT (I'm talking in Visual Studio context)
Basically for any library you want to use in any C++ project:
You need to include HEADERS in your project properties
You need to link to actual implementation of the library. You can read about
static and dynamic libraries (Someone on SO must have given an
awesome explanation)
I'm developing an application using Qt and OpenGL, and found it necessary to download the GLM library. It's a header-only library, so I don't need to link to anything. I want this application to build on any system that has the correct libraries installed. My problem is that I don't know where to put GLM so that the system can find it without adding a specific path to the project's .pro file. The .pro file is part of my git repository, which is how the source is distributed to other systems like Linux, etc. So I don't want this file to specify the exact location of GLM because other systems could have it in other places.
I'm currently developing on Windows, compiling in Qt Creator using Visual C++ 2010. I read from MSDN that #include <file> searches using the INCLUDE environment variable, so I tried to add the path to glm.hpp to INCLUDE, but QtCreator's build environment for this project seems to overwrite INCLUDE. So I appended the path to GLM to the new INCLUDE from within QtCreator's Projects tab, but my code still can't find glm.hpp.
In general, how can I add an external library to my system such that my compiler will be able to find it without specifying the exact location in a project file that's distributed to other systems?
What you need is a build system with the power to search the system for the libraries you request, and be able to do so on any platform. One such build system is cmake, and it is the most widely used build system. In essence, cmake allows you to write a build script in which you can specify all the things you normally specify when creating a project in Qt Creator or Visual Studio, like the list of source files, grouped by targets to compile (libraries, executables, etc.), the relative paths to the headers, and libraries to include for linking and for include-paths, amongst many more things. For libraries that are installed on the system, there is a function, called find_package() (part of cmake script commands), that will find out if the library is installed and where to find its lib files and headers (storing those paths as cache strings that you can specify on the targets and such). It usually works great, as long as the libraries are not installed in weird places. The way it works is that when you run cmake, it will generate a build script/configuration for almost any platform you specify, and then you use that to compile your code. It can generate makefiles (Unix-like or windows), CodeBlocks project files, Visual Studio project files, etc.. And many IDEs also have native support for cmake projects.
I wish I could recommend an alternative, just to sound less biased for cmake, but I haven't heard of any that truly compare to it, especially for the purpose of locating external dependencies and working with different platforms. I would guess Boost.Build is decent too.
I'm having my first fling with the Boost libraries, and I've picked a pretty girl named Regex.
I've installed the libraries (which build automatically?) on my machine, but I'm getting the above error (cannot find -lboost_regex). I'm using Code::Blocks with MinGW, and a C++0X compiler flag.
I have
Pointed the "search directories" to the installation directory
Added the -lboost_regex flag to the linker
but no luck. Can someone help me get this working?
Update
Got things running now. I've added some further notes in an answer below, for newcomers to this problem.
(Also, changed the title of the question since it turned out to be a broader issue than when I started out.)
Here's some links and tips that can help a newcomer, from my first build experience. I built the libraries directly from the zip file. I built on MinGW and I used CodeBlocks for the IDE.
Download Boost zip, unzip somewhere (I'll call that place $boostdir)
Pretty large when unzipped, > 300MB
Add MinGW bin to PATH var
When Boost builds, it will need access to MinGW executables
Build b2.exe and bjam.exe
The documentation for Windows blithely assumes MSVC compiler is available.
If it is, you can apparently use the bootstrap.bat like the docs say.
If it's not (like mine), you'll have to build the exe files yourself, in steps 4 and 5.
In CMD, navigate to $boostdir/tools/build/v2/engine
Run build.bat mingw (will build b2.exe and bjam.exe)
Some aging basic documentation on that
Now you've got b2 and bjam custom-built according to your system spec. Navigate back up to $boostdir and get ready to start building the libraries.
Boost will make a new bin.v2 directory in the current directory.
All the libs will go in bin.v2.
This is an "intermediate" directory, for some reason
Nothing to do in this step, just some extra info :)
Run b2 toolset=gcc --build-type=complete
This takes a long time, in the neighborhood of 1 - 2 hours.
You'll know if it's working. If you think something's wrong, it's not working.
The build can use various flags
Now you're all built. Time to set up CodeBlocks.
Point your compiler to the header files
Right click your project -> Build Options -> Search Directories tab -> Compiler tab -> add $boostdir address
Boost has built a DLL for the library you want according to your current system spec. Look in the stage\lib\ directory of $boostdir
This DLL will be used later in the linker, so don't close its explorer window yet
Mine was in C:\Program Files\Boost_1_52\stage\lib\libboost_regex-mgw44-1_52.dll
I think the documentation had a smart way to do this but I haven't tried it yet
The "intermediate" directory from step #6 can be deleted now that the build is finished
Point your linker to the directory of that DLL
Right click your project -> Build Options -> Search Directories tab -> Linker tab -> add
that directory address (blah\blah\blah\stage\lib\)
Add that DLL flag to your linker settings
Mine was -lboost_regex-mgw44-1_52
Deep breath, prayers to your god, and fire up a test.
Further docs that may either help or confuse:
The Code::Blocks website has a version of this that I didn't find until I neared the end of my search. It was fairly helpful but had a few weird things. This post also is helpful.
Good luck!
I'm not sure what you mean by which build automatically. Most of the Boost libraries are header-only, but a few, such as regex, need to be compiled to a shared / static library. The compilation step is not automatic, you need to invoke the Boost build system (bjam) to do this. Of course, there are sources (BoostPro for instance) that distribute pre-built Boost binaries for various platforms.
Once that's done, you need to add the path where the libraries are present to the linker's search path. For MinGW, this option is -L"path/to/library". Boost does have directives to allow auto-linking of the required libraries, and this seems to work pretty well with MSVC, but I've never gotten it to work with MinGW. So you must also list the libraries to be linked explicitly. The Boost libraries include target and version information in the file name by default, so a typical linker command line option will look like -lboost_regex-mgw47-mt-1_51 for MinGW gcc 4.7 and Boost 1.51
I am trying to use Eclipse on an existing collection of folders with C++ and recursive Makefile files in Linux. The make files use gcc and ar, and the user specifies the path to the gcc he wants to use in the Makefile. The make files that I will be working with were typed by hand.
In Eclipse, there is an option to create a new project that looks appropriate for what I need: "Create a new Makefile project from existing code in that same directory".
* <none>
* cross GCC
* GNU Autotools Toolchain
* Linux GCC
Here I have two questions:
Which toolchain should I choose? and how does Eclipse use this information?
I would like Eclipse to infer as much as it can from the top-level Makefile (e.g. include paths, make targets, etc) . How can I do this?
Your question is very similar to what I have setup for my project.
If the target platform that the application is expected to run on is the machine you are compiling on, the you ought to select Linux GCC.
If the target platform that application will run on is eg an ARM processor, you need to specify cross GCC.
The GNU Autotools Toolchain is designed to build source-code packages on different linux systems.
By selecting "Create a new Makefile project from existing code in that same directory" eclipse will assume that the user's makefiles will manage the build itself.
For eclipse to infer include paths, have the discovery options enabled in the project settings. Admittedly, your top-level make needs to specify include path, source-code paths etc.
You really can only eiter allow Eclipse to create the makefile for you based on what you have in your project or tell it which command to run when you select 'build'. Mixing these options I have found doesn't really work. If you are specifying the Makefile then the compiler used doesn't really matter either since the Makefile will define that. Just pick an 'empty c++ project' when you create a new project, make sure you specify not to use the 'default workspace' location and point this input box to your code base instead. In the project c++/build settings make sure that the "automatically generate makefile" is unchecked and specify what command should be executed to make your project. (usually this is 'make all' but it might be different for you)