I have tried to install igraph by running the following commands (as described in the manual):
./configure
make
make check
make install
The installation instructions do not provide any further information where to go from here however. How do use the files in my ongoing projects (for instance in Eclipse)?
According to the manual, the installation process is adding files to the 'usr/local/bin', but this folder is empty after the installation (no hidden files).
What would be the easiest way to use the files in my C++ projects?
The installation process is adding include files in /usr/local/include (more precisely in /usr/local/include/igraph only) and library files in /usr/local/lib. Stick /usr/local/include to your include path in Eclipse, add /usr/local/lib to your library path in Eclipse, and add igraph to the list of linked libraries, and you are good to go. Make sure to use #include <igraph/whatever.h> in your C++ code to include igraph-specific stuff.
Also, this project tries to provide a more C++-like API for igraph. It is still experimental, the API changes all the time and many igraph functions are not wrapped in C++ equivalents yet, but it's a starting point that you can extend.
Related
I would like to use the range-v3 library in my project, but i don't understand how. The installation description says the following:
This library is header-only. You can get the source code from the
range-v3 repository on github. To compile with Range-v3, just #include
the individual headers you want.
Does that mean I can copy and paste the needed header files and add the filepath to my CMake file? I am a bit confused, because I never included third party library.
Note: please see hythis' answer for a better solution.
Does that mean I can copy and paste the needed header files and add the filepath to my CMake file?
Basically, yes. First git clone to <path_to_range_v3>. Then include these lines into CMakeLists.txt:
add_library(range_v3 INTERFACE IMPORTED)
set_target_properties(range_v3 PROPERTIES
INTERFACE_INCLUDE_DIRECTORIES <path_to_range_v3>/include)
target_link_libraries(your_target PUBLIC range_v3)
I'm not sure why Evg suggested what they did, I don't even think in 2019 you were forced to create your own CMake interface with ranges-v3 (see here, the file existed way before hand). Regardless, don't use Evg's solution, ranges-v3 is a good header only library, and in order for a header only library to be good it must provide CMake integration.
Header only libraries do not mean the authors do not provide CMake support, or even avoid CMake themselves. Bad authors do this, as you've probably experienced by having to ask this question in the first place.
To properly integrate with Ranges V3, use a packagemanager (though some package managers screw the process up depending on how their custom CMake files are configured) such as Conan or vcpkg and integrate with their respective CMake solutions, or add the project as a git submodule (though you could git clone it as well) then in your CMakeLists.txt:
add_subdirectory([path to submodules]/range-v3)
...
target_link_libraries(my_target [SCOPE] range-v3::range-v3)
It can be hard to figure out actual targets for libraries if the authors don't spell out how to use their projects in a CMake project, and I don't blame any one making an SO post about it, it's a pain.
Generally if the project has a CMakeLists.txt file, it probably has static-library/sub_directory cmake integration, but some libraries only have install targets, thus are unusable when baked into your source code with out editing their CMakeLists.txt
To check if this is the case, or if you can actually use the targets, if you can't find any CMake documentation about how to use the library (which I couldn't) do the following:
Look inside the CMakeLists.txt file
Find a project alias usually in the form of project_name::project_name. This is how I found range-v3's project alias.
If you can't find alias (via searching for ::), find the actual target name for the library (and try to use this directly), sometimes this isn't exported though (hidden in a sub directory from the top cmake file). OpenCV doesn't use :: for example, and instead each component target is marked with opencv_[component name] but still exported.
If the project has not been configured to be properly used as a submodule and is otherwise meant to be used as a static library, submit an issue or PR to the given repository, this is a bug.
I have never had to use libraries other than ones that I have created, and even then I have simply copied the source files into the same directory as the remainder of the project. What are the steps to install and use libusb? I know that it is required to indicate to your respective IDE the pathway to the library, but to what exactly? To the folder containing the source? Is it necessary to precompile the libraries first?
I am not sure what to download from that link to get this going. There are options to sync via a repository to have the most up-to-date source, but is that necessary? I downloaded the tarball and have the source, but am not sure where to go from here.
Your compiler needs to know the path to the headers (.h), to find them when you #include and know which symbols (functions, structs ..) are available. Your linker needs to know the path to the corresponding compiled libraries (.o/.a/.so) containing the implementation. You don't need the source code (C/C++ implementation code, "private" headers) to use a library.
What you download depends on how you want to install it. If you are using a Linux distribution that already packages it, you can just install it using your package manager. You can get the newest version of libusb throught GitHub too, it is only "necessary" if you want something that is in the newest version. You can compile and install it in your /home or system wide. You can keep the sources in a separate directory next to your project's sources (git submodule can help to manage that), and compile them at the same time as your project. How you install them is your choice, then you just need to configure your IDE/build system accordingly.
I've downloaded, extracted, and compiled the Boost libraries (including the separately compiled libraries). I've used their install procedure a couple times now but I can't seem to get it to do exactly what I want. Right now, when I install Boost after compiling it goes to
C:\Boost
This is fine. The compiled libs go to
C:\Boost\lib
which is also fine. The problem I have is with the installation of the precompiled headers. They got put at
C:\Boost\include\boost-1_54\boost
Is there a way to use the Boost build system and install tools to set the precompiled headers to be installed to just
C:\Boost\include
and not have the Boost version number be a part of that folder hierarchy?
I don't plan on using multiple versions of Boost at the same time so I don't have a use for actually having that version number. I realize I could move them manually after the install is complete, but I wanted to see first if I've overlooked or misunderstood something about Boost's build system.
--layout=system removes the versioned subdirectory from the include path (as #IgorR. pointed out).
"Removing that second boost in the path" is a bad idea. In a respectable OS (cough...), the include files for various libraries are supposed to co-exist in one common include directory, hence the boost subdirectory to avoid clashes. Boost headers are therefore habitually referred to as e.g. #include <boost/any.hpp>, i.e. including that boost/ subdirectory.
This is done both by third-party software using Boost, and by Boost itself. If you remove the second boost from the path, you would end up with C:\Boost\include\any.hpp, and any Boost-using software won't compile as not even Boost could find its own includes.
I've built boost from source because I need the latest version to build pyopencv with.
That all went fine.
However, bjam now can't find the boost libs or includes because now they're no longer in /usr/lib, now they're in /usr/local/lib and /usr/local/include.
(I did add /usr/local/lib to LD_LIBRARY_PATH)
Now bjam complains:
boost-build.jam:2: in module scope
rule using unknown in module
on the first line of my boost-build.jam which says:
using python;
How do I tell bjam where to look for includes? I've looked at the Boost.Build docs, but can't seem to make out how to set the include path.
It's not the Boost headers failing to find (yet), it's the BoostBuild2 sources it's failing to find. You either need to use the BBV2 sources from the Boost tree, or install BBv2 separately (the BBv2 install is explained here). Assuming you read the Boost Python documentation on how to get started using that library (see the BPL docs).. You need to also follow the instructions on how to modify the startup/template BBv2 project in those instructions to build your own Python extensions using BBv2 (see the Modifying the Example Project, Relocate the Project section).
Also note that the line above you have should be: using python ; -- I.e. the spaces are important.
I'm trying setup a subset of boost and get it properly compiled using bjam, however I'm not getting the result I'm looking for. I'm working on windows using boost 1.37.0.
Let's say I want the libraries smart_ptr and filesystem built/installed. I intentionally chose a header only library and one library needing to compile a library. I want them to be built into a directory structure similar to the one I would get if I built a complete boost installation with bjam (i.e not specifying any --with-libraryX) but of course without all the libraries I'm not interested in.
My first approach was to use the --with-filesystem --with-smart_ptr in bjam, however it seemed like it didn't recognize smart_ptr (I tried smartptr and smart-ptr without success). I guess this is because it's a header only library.
When I removed it and only had --with-filesystem it seemed to copy ALL libraries header files to the install path and only build the libraries for filesystem. The library building behavior was the one I hoped for, but I got tons of header files for libraries I'm not interested in installed in my boost directory.
My second approach was to use bcp to copy the relevant projects. This did work out in the sense that I only got the projects I cared about (and their dependencies). However they didn't provide any make files for building the libraries that was copied. This means I would need to setup projects files for all the libraries that are not header only and manually build them.
So my question is basically, is there a way of selectively building boost that only copies the headers for the libraries I'm interested in and only building library files for the non header only libraries I'm interested in (and the boost libraries they are dependent on course)?
There are probably tons of manual/scripting based solutions for this, but if I could get something running only using bjam would be way more useful for me since adding new libraries or upgrading to a new boost version would be very simple.
EDIT:
Added the complete command line for the first approach:
bjam install --prefix=c:\temp\boostsmall
--build-dir=C:\temp\boostsmalltemp --layout=system
--with-filesystem variant=debug link=static threading=multi
runtime-link=static
Changed scoped_ptr to smart_ptr
Solved it.
The bcp solution had make files for the projects, however I needed to copy the tools directory and the root of the boost directory to the place I copied all my libs to get things up running.
Great question! This is an issue I have recently managed to figure out, I think.
I already had the full Boost libraries installed, including the ones requiring separate compilation.
I managed to create a subset of the Boost libraries (regex) for a particular application I was working on using the following steps:
First ensure the bcp executable is installed in the first place. In your Boost root folder, navigate to the tools/bcp folder and run the bjam.exe in here. For me this created the bcp executable in [Boost path]\bin.v2\tools\bcp\msvc-10.0\release\link-static directory:
Then create the folder where you would like the Boost subset to reside. This might already be a folder for a Visual Studio project you are working on.
Run the bcp exectubale you created, making sure to include the libraries you wish to include, as well as the location of the boost root directory and the destination folder. Observe how the required Boost components (eg for regex) have been included in your destination folder.
bcp.exe regex --boost="C:\Program Files\boost_1_55_0\boost_1_55_0" C:\Projects\RegexProject\BoostLite
In your Visual Studio project set the Additional Include Directories and Libraries to point to the 'Boost lite' folder that was created.
One final thing - which I think is described previously - I needed to go to my regular Boost folder setup and copy the required stage/lib folder containing all the lib files needed for the subset version and copy them here, just a few regex-related lib files in my case.
I found that this worked for me. Any feedback from other persons experiences would be appreciated.
A blog posting describing the same thing can be found here.