In Qt 6.4.0, we can use such code to include qt components:
#include <QtCore/qchar.h>
#include <QtCore/qbytearray.h>
#include <QtCore/qbytearrayview.h>
#include <QtWidgets/qtwidgetsglobal.h>
But I found that the real paths of those .h file are NOT under such folder like QtCore, QtWidgets etc. , actually most of them are under such directory:
/Users/tony/Qt/6.4.0/macos/lib/QtXXX.framework/Headers/qtxxx.h
I'm wondering that since QtCore is not the real path but Headers, Shouldn't we write #include "Headers/qtxxx.h" ? how can #include <QtCore/qchar.h> such path works?
Using the -I argument
You have to tell to your compiler which directory you want to include to find the headers properly. For example in clang and gcc you can use this directory as -I argument, like this:
clang++ yourprogram.cpp -I /Users/tony/Qt/6.4.0/macos/lib/QtXXX.framework/Headers/
And in your source code you will write includes at this way:
#include "QtCore/qchar.h"
#include "QtCore/qbytearray.h"
#include "QtCore/qbytearrayview.h"
#include "QtWidgets/qtwidgetsglobal.h"
Note it uses " " instead < >, this means you are finding the included files relative to your compile options instead of your system.
Although this works, it's recommended to use relative paths of your project to point headers directories.
It's been solved: This phenomenon only shows on MacOS since MacOS uses "framework" to organize a set of lib and headers, which can be parsed by the clang-module name to the realpath.
Related
I am very new to cmake, but I am using it on Visual Studio to develop a program that has to run on linux. I need to include the following in this manner:
#include <xscontroller/xscontrol_def.h>
#include <xscontroller/xsdevice_def.h>
#include <xscontroller/xsscanner.h>
#include <xstypes/xsoutputconfigurationarray.h>
#include <xstypes/xsdatapacket.h>
#include <xstypes/xstime.h>
#include <xscommon/xsens_mutex.h>
However, the files are only recognize by visual studio when I do the following:
#include "xscontroller/xscontrol_def.h"
#include "xscontroller/xsdevice_def.h"
#include "xscontroller/xsscanner.h"
#include "xstypes/xsoutputconfigurationarray.h"
#include "xstypes/xsdatapacket.h"
#include "xstypes/xstime.h"
#include "xscommon/xsens_mutex.h"
The structure of my project in VS is fairly simple:
ANT
-out
-xscommon
-xscontroller
-xstypes
-ANT.cpp
-CMakeLists.txt
.
.
.
The includes I need are in the three xs folder, and I believe they have to be referenced with <> both in visual studio and when the code is compiled onto linux, as the references within each header are done in <> form, which is what causes this error:
xscallbackplainc.h:68:10: fatal error: xstypes/pstdint.h: No such file or directory
#include <xstypes/pstdint.h>
^~~~~~~~~~~~~~~~~~~
at compilation.
Concisely, I really just need to know what command (whether it be in CMakeLists.txt or somewhere else) will allow this kind of referencing within the project and the compiled project over ssh on linux. I am aware of the difference between #include "" and #include <>, I am however new to cmake, and have looked everywhere and cannot find an answer.
The simplest way to achieve this is using include_directories command. Simply add the following to your ANT/CMakeLists.txt:
include_directories(${CMAKE_CURRENT_SOURCE_DIR})
Though I would highly recommend using target_include_directories() instead. The difference between the two is that target_include_directories() specifies include directories just for one target[1].
[1]. A target is anything specified via add_executable() or add_library():
cmake_minimum_required(VERSION 3.12)
project(ANT)
add_executable(ANT ANT.cpp) #other source files as necessary
#format of target_include_directories:
# target_include_directories(target_name PUBLIC|PRIVATE PATH_TO_DIR)
target_include_directories(ANT PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})
I have posted the question about linking, hopefully it makes sense. Should be clear I don't know what I'm doing.
I have a class called Timer that contains, obviously, code to track running time. I want to include this class in another project but I can't figure out how.
I have tried using
#include "Timer.h"
as well as using the file path to the project with the timer class, i.e.
#include "/users/user/projects/TimerProject/timer.h"
But that hasn't worked either, it tells me the file can’t be found. Is there something I am missing here?
Yes. You need to tell your C++ compiler where to search for include files. For gcc or clang, this is the -I command-line switch. So, for example:
g++ -o foo foo.cpp -I/users/user/projects/TimerProject/
and this will allow you to use:
#include <Timer.h>
Using double-quotes around the include name tells the compiler: "Search the same directory as the including file first, then search the include folders the compiler knows about". So if you have a foo.h next to your foo.cpp, you could use:
#include "foo.h"
without adding anything to the include path for it.
Finally: Files are case-sensitive on many operating systems. In your example, you have Timer.h and timer.h - make sure you use the correct spelling!
See also:
What is the difference between #include <filename> and #include "filename"?
I am unable to compile a C project that uses a library called "FFmpeg" with a compiler called "GCC", and I believe it might be either because I don't quite understand how #include works or because I am using the wrong compilation process.
In a folder called Test, I have a file Test/test.c with the following contents:
#include <stdio.h>
#include <stdlib.h>
#include "FFmpeg/libavcodec/avcodec.h"
The folder FFmpeg is located at Test/FFmpeg. When I try to compile this with GCC, I receive the following error:
fatal error: libavutil/samplefmt.h: No such file or directory
The file Test/FFmpeg/libavcodec/avcodec.h has the following code in it:
#include "libavutil/samplefmt.h"
#include "libavutil/attributes.h"
#include "libavutil/avutil.h"
... //many more #include statements
Is the issue here that I need to add "FFmpeg/" to all of these include statements?
If so, is there a way to automatically do this? This library is enormous and probably has hundreds of these statements.
If not, what should I be doing instead? Should I attempt to compile the library by itself? If so, how do I then include this compiled version of the library in my program?
Notes:
The command I am using to compile is gcc -c test.c.
I have GCC installed via MinGW.
I ultimately need to be able to compile this program to both a .dll and an .so.
I apologize if any of the terminology I use here is incorrect or if my explanations are poor. I know almost nothing about compilation. Please let me know if I need to fill in more information.
When #include is used with quotation marks (e.g. #include "file path here"), it will read that file path as a relative file path.
In the case of compiling a C program using GCC, file paths are relative to the current directory. The "current directory" is the one into which you have placed your command prompt using the cd command.
In my case, I cd'd into C:/Users/User/Documents/Test, meaning that all relative file paths are relative to C:/Users/User/Documents/Test. So when my compiler read
#include "libavutil/samplefmt.h"
it basically tried to do this:
#include C:/Users/User/Documents/Test/libavutil/samplefmt.h
when I instead needed the compiler to look at …/Test/FFmpeg/libavutil/samplefmt.h.
It turns out that the solution to this is to give the compiler additional locations to which relative paths might be relative. This is done with the -I[file path here] argument when you compile.
In my case, the way I needed to use this idea was to add C:/Users/User/Documents/Test/FFmpeg as a location to which paths might be relative. Thus, I could have taken my compile command:
gcc -c test.c
And inserted this:
gcc -IC:\Users\User\Documents\Test\FFmpeg -c test.c
However, this is actually an extremely clunky solution. There is a much easier way: it turns out that these file paths you provide with the -I argument can be relative to your current directory themselves. In my case, because my current directory in the command prompt was alreadyC:/Users/User/Documents/Test, I could simply remove this portion from the above command, shortening it to this:
gcc -IFFmpeg -c test.c
And this solved my problem.
I just start learning opengl and I started with GLFW library.
And I download the "Windows pre-compiled binaries" from http://www.glfw.org/download.html. Then I unzip my file into C:\GLFW
And now I have a problem when compiling my code. I use mingw in command line, like
gcc main.c -IC:\GLFW\include\GLFW -LC:\GLFW\lib-mingw -lglfw3 -lglfw3dll -lopengl32 -lgdi32
It always show "fatal error: GLFW/glfw3.h: No such file or directory"
but if I change #include <GLFW/glfw3.h> into just #include <glfw3.h> in my code,
it compiles successfully.
But every tutorial shows me the former. Why?
If I put the header file and lib file into mingw's searching path, is there any different?
It is because you include directly to C:\GLFW\include\GLFW, so there is no GLFW folder in this directory. If you want to use #include <GLFW/glfw3.h>, you will want to use this path instead C:\GLFW\include.
To answer to your two questions:
The include path is very relative to you. What do you prefer, #include <GLFW/glfw3.h> or #include <glfw3.h>?
You can put the lib and header in the mingw's path, but you have to remember that you will still need to enter the good path (#include <GLFW/glfw3.h> if you put it in the folder). I would not recommend this method, since I prefer to make an include and lib folder into my project directory. If you want to do more research: http://www.mingw.org/wiki/includepathhowto.
I am working in ubuntu under c++ language.
I have a question: i use #include"header.h". Is this the same with /path/header.h? I ask you this question because as I've seen is not the same thing. Need some explications.
I ask you this question because I've downloaded and install gsoap on my computer. I added all the necessary dependencies in a folder and I've tried to run the app without installing gsoap ...on a different computer. I had some errors..i forgot to add stdsoap2.h file...I will add it today..in my folder..
The answer is it depends:
If you have "path/" added to your include path then including only "header.h" will work because then compiler already knows the path to lookup for your header files, if not
then you have to include entire path "path/header.h" so the compiler knows where to look for the header file.
If header.h is in the directory path/, then #include "header.h" will work for those header and source files (which #include header.h which happen to be in the same directory as header.h (path/).
On the other hand, if you are #include-ing header.h in a file that is in a different directory than path/, then the above way would not work. To make it work, you can try 2 different approaches:
#include the complete path to header.h. Your #include will look something like:
#include "path/header.h"
Include the path/ directory to the makefile. This will get g++ to look for header.h in those directories as well. This can be done like so (in the makefile):
g++ <some parameters> -Ipath/ -c main.cpp -o main.o (assuming header.h is called from within main.cpp). If you choose this way, then the #include will also change, like so:
#include <header.h>. Note the use of the -I flag as a parameter to g++. That flag tells g++ to look into additional directories as well.
No, they are not the same, conceptually. The results, however, could be the same. It depends on how you tell your compiler to find headers (the -I flag in g++). If you would compile with -I /path/, then you'd find /path/header.h with #include "header.h". If you do not use that include path flag, then you'd have to write #include "/path/header.h".