I'm working on a relatively big project that is using automake build system.
Now the problem is that I need to link the project with a library from another project (this works fine), but I also need to include a header from the other project source tree (api.h).
INCLUDES = -I#REMOTE_PROJECT_DIR#
in Makefile.am doesn't work, because there are .h files with coliding names in the remote source directory. How can I add just the api.h?
I used a symlink into the include directory in the project, but now I need to push the sources into a public repo and everyone working with it has the other project in a different directory, so I need to use the configure param.
You do not want to tweak you Makefile.am or your configure.ac in any way. If api.h is installed in a standard location (eg /usr/include), then all you need is AC_CHECK_HEADERS([api.h]) in configure.ac. If api.h is installed in a non-standard location (eg /home/joe/include), the way to pick it up in your project is determined at configure time. When you run configure, you add the argument CPPFLAGS=-I/home/joe/include to the invocation of configure. You do not indicate the non-standard location in the build files themselves.
Another alternative is to use pkg-config, but the non-standard location of your header file will still be dealt with when you run configure. (This time by setting PKG_CONFIG_PATH rather than CPPFLAGS)
If you have headers with same names, you could put at least one of them into directory with different name and include it using directory name.
Here's a sample directory structure:
mylibrary/include/myblirary/api.h
myproject/api.h
myproject/main.cpp
In main.cpp:
#include "api.h"
#include "mylibrary/api.h"
#include <boost/regex.hpp>
When compiling:
g++ -I mylibrary/include
Related
I've been given these source files and headers. In the README.md the authors explain how to launch the test executables without the need of a proper installation. It is just a make command to run. They explain how to generate the .so files. I think these latter are meant to be used if I wanted to install the APIs at a system level (the definitions should be in api.h). My question is: where should I copy the shared objects generated by the Makefile and the api.h header? I aim to write a source file from scratch where I use those APIs (e.g. crypto_sign()) just including the headers, if it is possible. Thanks
where should I copy the shared objects generated by the Makefile and the api.h header? I aim to write a source file from scratch where I use those APIs (e.g. crypto_sign()) just including the headers, if it is possible
Nowhere.
The project comes with CMake support. Use CMake in your project and just add_subdirectory the repository directory.
Anyway, if you really wish to install the library system-wide, then FHS specifies directory structure on linux. For local system administration use /usr/local/lib for local libraries .so files and /usr/local/include for local C header files.
I am working to build a Code Composer Studio project using cmake, which is new to me. It builds successfully under Linux but I am struggling to get it to work under Windows. The cmake command executes without issue, but make fails during the very first C object at the very first #include with the error code
fatal error: could not open source file "stdbool.h" (no directories in search list)
I'm using the libraries included in CCS's compiler (c6000_7.4.15), and that whole folder is included in the CSS project. I include it in cmake as well. In my .cmake file:
set (CCS_ROOT ${CCS_ROOT_V6_WIN} CACHE PATH "code composer install directory")
set(CGT_COMPILER_ROOT ${CCS_ROOT}/tools/compiler/c6000_7.4.15 CACHE INTERNAL "DSP Compiler Root")`
And in the CMakeLists.txt file:
set (COMPILER_INCLUDE ${CGT_COMPILER_ROOT}/include)
INCLUDE_DIRECTORIES ("${COMPILER_INCLUDE}")
Why can the header files not be opened when they're linked in the project and CMake can find them just fine?
EDIT: The directory structure had been changed underneath me, so I took the opportunity to add all of the external files directly into the project to make it completely platform-independent. That way, since the project is managed by our Git repository, users won't have to install the CSL or any other programs to build the project. This also means that paths to libraries and header files will never change between revisions and environments.
Unfortunately, this has not solved my problem. The project continues to build in Linux while failing to ind the very first included header file. I also notice that, under Windows, it cannot find my own header files unless I provide a relative path, e.g. #include "../Common.h" I can get make to find stdbool.h if I provide an absolute path to the compiler directory, but that exposes a web of additional broken links between files.
As a side note, the project builds successfully within Code Composer Studio, so I am assuming that this isn't an issue with my specific Windows environment nor with the code within the project itself.
This seems to be an issue with gcc.exe. I set an environment variable CC to the path of a different compiler (in my case a TI compiler) within my build script and that fixed the problem.
I'm working on packaging a library which has a bunch of header files, and a .a static library.
The C headers for the library are all in the root folder of the library, but the headers use some external typedefs held in a common/ directory.
I tried copying all the .h files into a directory /usr/include/libcapriltags, and all the common/*.h files into /usr/include/libcapriltags/common.
Then I symlinked the main .h file from /usr/include/libcapriltags/apriltag.h to /usr/include/apriltag.h
I also put the .a file in /usr/lib.
I could link against the library, but when I imported apriltag.h, gcc couldn't find anything in /usr/include/libcapriltags/common.
What am I doing wrong installing the library?
Supposing that the "library" headers reference the shared internal headers via the form ...
#include "common/my_typedefs.h"
..., it is incorrect to both install those headers in /usr/include/libcapriltags/common and at the same time symlink /usr/include/libcapriltags/apriltag.h to /usr/include/apriltag.h. The symlink will also be an issue if apriltag.h refers to other headers directly in /usr/include/libcapriltags/ via double-quote syntax.
When the compiler locates /usr/include/apriltag.h, it is unlikely to know or care whether that's a symlink. Any relative lookup it performs for other headers #included by apriltag.h will be relative to the path at which it found apriltag.h (the symlink).
On the other hand, if any of these headers refer to each other via the angle-bracket include syntax, then the root issue is that the directory in which you've installed them is not in the (default) include search path. Your symlink does nothing to address that, except with respect to its specific target file.
Supposing that you do want to put all the headers in and under /usr/include/libcapriltags, which is perfectly reasonable, you should be prepared to add that directory to the include file search path when you compile code that uses them. The traditional compiler option for doing so is spelled -I/usr/include/libcapriltags. Depending on how they're written, you might be also able to reference them via qualified form (#include <libcapriltags/apriltags.h>). Either way, you neither need nor want to symlink any files from that directory into /usr/include.
I would like to add wpa_ctrl.h on a C code, and the source code has the following header files:
#include "includes.h"
#include "common.h"
how do I suppose to have them? Do I need to install any package or do they suppose to be at the kernel header files or in the include path? If I need to include it manually, then each file depends on some many header files that needs to be added manually, is there a convenient way to add the files that are needed
These files are part of the hostapd project, and internal header files that won't be installed so you can't just include them after installing the package.
You'd be probably better off just ripping out the parts from wpa_ctrl.h you need. Depending on what you need it might be even better to use e.g. the DBus interface to communicate with wpa_supplicant (if that's what you want).
You get them from wpa_supplicant source code.
Here's where to find them:
wpa_supplicant-2.4/src/utils/includes.h
wpa_supplicant-2.4/src/utils/common.h
I copied them into my project directory and everything worked.
Here's where to find the source code:
https://w1.fi/releases/
I'm using QTCreator as a code editor for my C++ project, not using the real features of the qmake compilation process.
My project has several subdirectories, in all of which I ran qmake -project to create a duummy .pro file that simply lists the source and header files in the directory.
In my root folder, I simply created a "main.pro" file that includes all these "subdir/subdir.pro" files.
So it looks like this:
./
main.pro
subdir1/
/include
/src
subdir1.pro
subdir2/
/include
/src
subdir2.pro
Now my problem is, I use some files that have a special file extension (say, .ccp), which are actually some C code but are used in a different step of my compilation process.
They are naturally ignored by the qmake -project command and do not appear in my project.
I read here that I could use the qmake setting QMAKE_EXT_CPP to tell it to gather my files as a C-code file, but it doesn't seem to be working.
If I run qmake -query QMAKE_EXT_CPP, I get .cpp::.c::.ccp (which I set right before), but when running a new qmake, it doesn't take my .ccp files in account.
So, three questions:
Is it possible to make qmake take some special extensions as a C++ file, when building the .pro file?
If yes, is it correct to use the QMAKE_EXT_CPP setting?
If yes, what should be the syntax of the QMAKE_EXT_CPP setting? (mine inspired by this forum post, but it might be bogus).
You cannot change QMAKE_EXT_CPP with -project option. The list of cpp extensions used at this stage is hardcoded into qmake. However after initial creation of .pro file you can edit it to extend with support for other extensions:
in test.pro
QMAKE_EXT_CPP += .ccp
SOURCES += test.ccp
You have to add new files manually.