Compiler: Mingw GCC compiler
In make file I specified src directory location like below..
dirsrc = ./src
So here I mentioned current directory. The problem is the generated DLL having the Absolute path to the source directory. Is there any way to notify the compiler which should be relative.?
Because I am generating this DLL with Codecoverage information. If I moved my full project structure to somewhere means while simulating the DLL to target, at that time the DLL refers to the absolute path of the source directory.
I need the DLL with relative path to the source directory.? How do I write the make file with relative path to the source directory?
The real problem is,
I am doing code coverage analysis using gcov.
I followed following steps:
1.) I compiled my program with GNU CC options: `-fprofile-arcs -ftest-coverage'.
2.) I got 2 additional file with suffix *.bb and *.bbg in same directory
3.) Running the program will cause profile output to be generated.
For each source file compiled with -fprofile-arcs', an accompanying .da' file will be placed in the source directory. The name of the .da' file is stored as an *_absolute pathname_* in the resulting object file. This path name is derived from the source file name by substituting a .da' suffix.
The problem here is that I am compiling on one machine and running on a seperate machine. Each '.da' file has absoulte pathname in the resulting object file. So it does not find same path on another machine.
Is it possible to have fprofile-arcs and any other profiling-related options in GCC to have file names relative rather than absolute.
please let me asap.! thanks in advance.
Related
I am working with a library that nominally stores its internal headers in a directory that is not itself on the include path, although its parent is. Including the intended entry point header ends up failing because it links to other internal headers via quoted include without the directory name.
I do #include <SDL2/SDL.h> which the compiler does find, in /usr/include/SDL2/SDL.h on my system, but it then fails to find "begin_code.h" which is included several layers deeper in SDLs internal header code.
In file included from /usr/include/SDL2/SDL.h:32:
In file included from /usr/include/SDL2/SDL_main.h:25:
In file included from /usr/include/SDL2/SDL_stdinc.h:31:
In file included from /usr/include/SDL2/SDL_config.h:4:
In file included from /usr/include/x86_64-linux-gnu/SDL2/_real_SDL_config.h:33:
/usr/include/x86_64-linux-gnu/SDL2/SDL_platform.h:179:10: fatal error: 'begin_code.h' file not found
#include "begin_code.h"
^~~~~~~~~~~~~~
1 error generated.
Adding -iquote /usr/include/SDL2 manually works in my case, but what about in build environments where the SDL2 headers were downloaded to some local directory? The point of cmake is to work with local configurations that vary, so adding a hard-coded single path based on platform would be dumb. I want some future person who wants to compile my code with the SDL2 headers downloaded to ~/projects/headers/SDL2 to be able to compile after specifying only ~/projects/headers to their include path, for example, so they don't have to deal with SDLs internal issues.
It seems to me that all I need is to iterate on every dir on the -iquote path and, if it contains a directory name SDL2, add that directory to the -iquote. Does cmake make available the (system configuration dependent) -iquote path as an traversable list?
This question is my attempt to rephrase this unasnwered question for clarity.
Edit: I get that cmake is not responsible for fixing the issue, but cmake (or, rather, a CMakeList.txt file in my project) should be capable of working around this SDL bug. Hard-coding the assumed path is only reliable for build systems that install SDL2 headers via some standard package manager. I've never seen a unix dev manually download header files and stick them in the system include path, for fear that they might be overwritten or otherwise conflict with a future install of an official headers package. There are other valid places to put include files, so cmake should be able to search them. Isn't eliminating hard-coded paths half the point of cmake?
CMake doesn't provide a way for a custom iteration over include directories.
Instead, you could reformulate your intentions into the form "find a directory with the given header".
That form is expressed with command find_path, which is a natural way in CMake for search include directories.
E.g. that call:
# Task for CMake: Find a directory with "begin_code.h" header in it.
# Possibly, this is subdirectory 'SDL2' of a "normal" include directory.
find_path(SDL2_INCLUDE_DIR_1 "begin_code.h" PATH_SUFFIXES "SDL2")
will fill the variable SDL2_INCLUDE_DIR_1 with the directory containing the header begin_code.h.
This way works perfectly in case of local installation of SDL2, if that installation is hinted for CMake with CMAKE_PREFIX_PATH variable. For support other hints, e.g. SDL2DIR environment variable, you need to add appropriate PATHS options to your call:
find_path(SDL2_INCLUDE_DIR_1 "begin_code.h" PATH_SUFFIXES "SDL2" PATHS ENV SDL2DIR)
If you feel that SDL2 developers could rename the problematic file, but expect that file to be near the SDL2.h, then you could change the above command to search SDL2.h instead of begin_code.h:
find_path(SDL2_INCLUDE_DIR_1 "SDL2.h" PATH_SUFFIXES "SDL2" PATHS ENV SDL2DIR)
How to tell CMake that directory is generated so that it doesn't complain before building process that directory doesn't exist?
My library project is used by many clients and for every client I have client-specific configuration generated by scripts and placed into generated/[client-name]/generated.h header. So for every client there's is folder generated. But parent project source files (*.cpp) include just generated.h. I wanted to add generated/[client-name] interface include directory for my library by using:
set_target_properties(mylib PROPERTIES INTERFACE_INCLUDE_DIRECTORIES "generated/myclient" ...)
but CMake complains even before starting compilation - Imported target "xxx" includes non-existent path. So I guess CMake doesn't like that include directory is missing when it starts building process although target depends on other targets which should create correct directory & header file within it.
You can create the directory first with CMake:
file(MAKE_DIRECTORY "generated/myclient")
This will have no effect if the directory exists already.
I have a project where compilation and test running is managed by cmake. The test involves reading a special test file, which is located in different directory from the test file and would need an absolute path. I define the path to the testfile in my tests.cpp like this:
#define ARPA_TESTFILEPATH "/path/to/project/root/arpa/toy_lm.arpa"
I want to pass that define via cmake so that other people can checkout the project and run the tests without modifying anything. I know I can add defines in cmake via:
add_definitions(-DARPA_TESTFILE="/path/to/project/root/arpa/toy_lm.arpa")
However how can I add a variable to the define so that it automatically resolves the path? I am looking for something like:
add_definitions(-DARPA_TESTFILE="$(PROJECTROOT)/arpa/toy_lm.arpa")
Is that possible?
EDIT:
Basically say the project is checked out in a directory
/home/pesho/project
the project directory contains CMakeLists.txt. How could I get the absolute path to the projects directory so that I can include it in a variable and then define it during compilation.
Put the path in a CACHE variable. It make it accessible through ccmake command :
set(PATH_TO_ARPA "${DEFAULT_PATH_TO_ARPA}" CACHE FILEPATH "Description of the option")
See documentation : http://www.cmake.org/cmake/help/v3.0/command/set.html
In the main folder of my project, I have a CMakeLists.txt file. Inside this file, I include (using add_subdirectory) another CMakeLists.txt file located in my header file directory. The responsibility of this second file is to add all of my header files to the project:
file(GLOB gl_nbody_HEADERS "*.h")
add_executable(gl_nbody ${gl_nbody_HEADERS})
However, this files causes an error:
CMake Error: CMake can not determine linker language for target:gl_nbody
CMake Error: Cannot determine link language for target "gl_nbody".
What is strange is that when I include the two lines causing this error in my main CMakeLists.txt file (modified to work correctly for the change in directory), it works fine.
What is going wrong here?
add_executable causes the creation of an executable target, meaning the compilation of a list of source code files into an executable binary.
In order for this to work, and have CMake select a suitable compiler, the list of source files must contain at least one file with a "compilable" extension, ie. .c, or .cpp, or .cxx....
I don't see why you are trying to compile an executable here, since you only seem to try to list header files for inclusion into a project (which only makes sense for IDE-based generators, such as Visual Studio).
Also, it is not recommended to use globbing of files in CMake, because if you add more files to your project, CMake cannot detect them automatically, and will not regenerate build files. Please list all files explicitely.
The proper solution here is to list the header files in the proper add_executable command call where you list the actual source files that you want to compile.
You might also want to use the source_group() command, that allows you to group files into folders in the generated Visual Studio solution, for example:
source_group(header_files ${gl_nbody_HEADERS})
I'm very new to EFL. And now I'm trying to get used to it. There is library named Edje. This library allows theming and other sort of things. But files for it are created in plain text and have to be compiled using edje_cc.
How can I add this compilation to CMakeLists.txt file and to packaging.spec file for it to be properly compiled and installed on the machine?
Sorry for my broken English.
In your CMakeLists.txt, do:
ADD_CUSTOM_TARGET(your_edj_file.edj
COMMAND edje_cc your_edc_file.edc your_edj_file.edj
)
Notice that I simplified the COMMAND line - add the same arguments you use when you run edje_cc on a terminal (e.g. -id for images dir, -fd for fonts dir).
With this line added to CMakeLists.txt, a call to cmake in your packaging.spec file should be enough.