The OpenCL specification writes in 5.6.3 Build Options:
5.6.3.1 Preprocessor options
...
-I dir
Add the directory dir to the list of directories to be searched
for header files.
Can someone please explain what that means? As far as I know you cannot inlcude header files into your OpenCL kernels. So what could this options be for?
EDIT: Link to the OpenCL spec: http://www.khronos.org/registry/cl/specs/opencl-1.1.pdf
EDIT2: I was under the wrong assumption that it is not allowed to include header files into ones OpenCL kernel. Now I know better, thanks to jHackTheRipper.
It allows you to add some directories containing header files which are not in the standard include-search path. This way you can tell the compiler where those particular header files are located on your system.
For instance, suppose the file foo.h is not in the standard include path (commonly /usr/include on a Unix system), but rather in /home/foo/my_headers/foo.h, you can ask the compiler to search /home/foo/my_headers for header files by doing:
g++ -I/home/foo/my_headers foo.c -o foo
To be complete, the section title introduce the word preprocessor which is the program called before the compiler to replace all #something directives by their equivalent. #include <foo.h> will be replaced by the content of the foo.h file.
I include the headers for development, but for releases I process all of the headers and dependencies into one file, and then embed that source in the binary.
Related
Where is the following syntax used in a feature configuration (.prf) file? defined:
$$[QT_HOST_DATA/get]
I know $$[ ... ] is to access QMake properties as explained in the Qt doc, but where is the /get part of the notation in $$[QT_HOST_DATA/get] clarified? And what does it precisely do?
Also, inside a Qt .conf file, what is the difference between include (for other .conf files) and load() (for .prf files)?
If include(some.conf) merely consists in the contents of some.conf to be literally pasted into the including .conf file, what does load() do exactly?
I have found no info about the structure of .prf files.
https://doc.qt.io/qt-5/qmake-advanced-usage.html says that you can create .prf files, but says nothing about how these files are processed or should be structured?
Thanks for any clarifications you can provide!
where is the /get part of the notation in $$[QT_HOST_DATA/get] clarified? And what does it precisely do?
Nowhere, except qmake source code. It looks like all qmake properties may have upto four special "subproperies": xxx/dev xxx/src xxx/raw xxx/get. However, what are they used for is a mystery. Executing qmake -query QT_HOST_DATA/get produces (on my machine) just the same value as plain $$[QT_HOST_DATA].
I have found no info about the structure of .prf files.
Basically, .prf is just "system include file". There are two points, though:
All .prf files reside in a known location(s) pointed by QMAKEFEATURES variable.
BTW. QMAKEFEATURES is a sort of "protected variable". I managed to change it only with the help of (another undocumented) cache() function:
QMAKEFEATURES *= mydir # '*=' because of 3 passes under Windows
# 'transient' prevents creation file on disk
# only 'super' seems to work OK; no idea what's wrong with 'stash' or 'cache'
cache(QMAKEFEATURES, set transient super)
# now I can load .prf from <mydir> too...
Prf can be implicitly loaded by mentioning it in CONFIG variable. For example, CONFIG += qt (which is the default, btw.) results in include of <SomePrefix>/share/qt5/mkspecs/features/qt.prf Note that this takes place after the whole .pro was processed, so .prf file can be used to post-process user options.
what does load() do exactly?
It's just the version of include() designed specially for .prf. All it does, it simply includes .prf file. But, unlike CONFIG += xxx, it does this immediately, and, unlike plain include(), you shouldn't specify path and extension.
I'm new to OCaml, but I'm trying to figure out the equivalent of __filename, __dirname from Node. That is, I need to build a path relative to the file containing the code in question.
For reference, I'm working through Ghuloum's IACC: http://ell.io/tt$ocameel
I'm building my first compiler, and I have an utterly-simplistic ‘runtime’ file (in C — temporarily) adjacent to the compiler's source-code. I need to be able to pass the path to this file, as an argument (or a pre-compiled version, I suppose) to gcc or my linker, to have it linked against my compiler's output when I invoke the linker/assembler tooling.
(This may be a stupid question — I'm at a bit of an unknown-unknown here, “how does a compiler get the runtime to the linker”, or something like that. Any commentary about idiomatic solutions to this is welcome, even if it's not a direct answer to the above question!)
If you're running the source file directly via ocaml myfile.ml, Sys.argv.(0) will give you the path to the source file and you can use Filename.dirname to get the directory from that.
If you first compile the source file into an executable and then run the executable, Sys.argv.(0) will give you the name of the executable. In that scenario it's impossible to get the location of the source code (especially if you consider that the person running the executable might not even have the source code on their system).
If you set up your project structure, so that your sources live in src/, your compiled binary in bin/ and the compiled stdlib in lib/, you could just use Filename.dirname Sys.argv.(0) ^ "../lib" as the library path for gcc. This will work whether you run ocaml src/mycompiler.ml, bin/mycompiler or just mycompiler after installing everything to /usr/ or /usr/local/.
Within the .pro file, things are straightforward if you're including header files (use HEADERS), C++ files (use SOURCES) and Objective-C / Objective-C++ files (use OBJECTIVE_SOURCES), but it is less clear to me how other file types should be included.
e.g. looking at various examples that Qt provide, there is inconsistency about whether QML files should be DISTFILES, OTHER_FILES or contained within a .qrc file (i.e. RESOURCES). I've gone with putting QML files in a qml.qrc file.
My question has arisen because I'm including data files, such as audio .wav files, within a .qrc file (also as shown in Qt examples; e.g. Qt Quick Demo - Maroon in Trouble) but this has slowed compiling down to a crawl. And in the case of MinGW on Windows, it simply crashes with an out of memory error when it reaches 1GB. There must be a better way to include these!
Could you provide a guide as to when to use:
DISTFILES
OTHER_FILES
RESOURCES
Quoting from the qmake manual:
RESOURCES
Specifies the name of the resource collection files (qrc) for the target. [...]
DISTFILES
Specifies a list of files to be included in the dist target. This feature is supported by UnixMake specs only. [...]
OTHER_FILES
This seems in fact undocumented, at least I could not find anything. As far as I can tell all files listed here are only linked in project explorer (of Qt Creator for example) and are not treated in any way by qmake.
As for your example you might consider shipping the files as they are and not include them in any resource file, because they are compiled into the binary.
You may also take a look at compiling external resources and using them for your large files to keep the simplicity of Qt's resource system.
DISTFILES: Something special for unix you won't use in most cases. From the docs:
Specifies a list of files to be included in the dist target. This
feature is supported by UnixMake specs only.
OTHER_FILES: Files, that are part of you project, but not of the "build". This can be things like a readme, build hints, or any other stuff, that does not fit into any other categories
RESOURCES: .qrc-files, that will be compiled into the application.
Regarding the usage of those three with QML:
You can basicly use DISTFILES or OTHER_FILES for other files. In QtCreator the appear in a node as other files. These two are exchangeable for most developers. The Qt examples are local project, thus either they don't require a resource or have both, i.e. you can find the QML-files in for example OTHER_FILES and RESOURCES.
For QML files, you should always use RESOURCES, to make sure they are within your binary.
Speaking of DISTFILES , you can try it yourself.
Assuming you are using Qt on Windows. Here is a very simple qmake project file project.pro:
TEMPLATE = app
DISTFILES += "C:\Windows\explorer.exe"
qmake it, and you can find the following statements in generated Makefile.Debug and Makefile.Release:
DIST = C:\Windows\explorer.exe
...
dist:
$(ZIP) project.zip $(SOURCES) $(DIST) project.pro
...
The target dist is one of the standard targets. I learned it from makefile - What is the difference between make and make dist? - Stack Overflow.
It is a known bug that moc trips over macros used in libstdc++ as documented here: http://lists.kde.org/?l=necessitas-devel&m=132317657926916&q=raw
I am trying to compile a project which uses gcc 4.6.3 and am stuck because moc trips over the macros.
One way to overcome the problem is to include the directives as mentioned in this link:
http://doc.qt.io/qt-4.8/moc.html
but that is time consuming and not a very clean way as every file has to have these directives.
What I'd like to know is, can qmake be configured such as to make moc skip certain directories/files?
edited: typos
According to the Qt qmake docs moc will be run for files that are added to the HEADERS variable (emphasis mine):
qmake will generate dependency information (unless -nodepend is specified on the command line) for the specified headers. qmake will also automatically detect if moc is required by the classes in these headers, and add the appropriate dependencies and files to the project for generating and linking the moc files.
So if you don't want moc to be run for certain files then don't add them to the HEADERS in your .pro file. However, for some platforms that might cause the headers not to be found when compiling the corresponding .cpp files. To fix that, add an INCLUDEPATH for the folders containing such headers - moc won't be run for headers that are inside an INCLUDEPATH.
I have a project (a library) that is subdivided into a few directories with code in them. I'd like to to have g++ search for header files in the project's root directory, so I can avoid different include paths for same header files across multiple source files.
Mainly, the root/ directory has sub-directories A/, B/ and C/, all of which have .hpp and .cpp files inside. If some source file in A wanted to include file.hpp, which was in B, it would have to do it like this: #include "../B/file.hpp". Same for another source file that was in C. But, if A itself had sub-directories with files that needed file.hpp, then, it would be inconsistent and would cause errors if I decided to move files (because the include path would be "../../B/file.hpp").
Also, this would need to work from other projects as well, which reside outside of root/. I already know that there is an option to manually copy all my header files into a default-search directory, but I'd like to do this the way I described.
Edit: all programs using the library must compile only with g++ prog.cpp lib.a -o prog. That means permanently setting the include path for g++!
A/code.cpp
#include <B/file.hpp>
A/a/code2.cpp
#include <B/file.hpp>
Compile using:
g++ -I /your/source/root /your/source/root/A/code.cpp
g++ -I /your/source/root /your/source/root/A/a/code2.cpp
Edit:
You can use environment variables to change the path g++ looks for header files. From man page:
Some additional environments variables affect the behavior of the
preprocessor.
CPATH
C_INCLUDE_PATH
CPLUS_INCLUDE_PATH
OBJC_INCLUDE_PATH
Each variable's value is a list of directories separated by a special character, much like PATH, in which to look for header
files. The special character, "PATH_SEPARATOR", is target-dependent and determined at GCC build time. For Microsoft Windows-based targets it
is a semicolon, and for almost all other targets it is a colon.
CPATH specifies a list of directories to be searched as if specified with -I, but after any paths given with -I options on the
command line. This
environment variable is used regardless of which language is being preprocessed.
The remaining environment variables apply only when preprocessing the particular language indicated. Each specifies a
list of directories to be
searched as if specified with -isystem, but after any paths given with -isystem options on the command line.
In all these variables, an empty element instructs the compiler to search its current working directory. Empty elements can
appear at the beginning
or end of a path. For instance, if the value of CPATH is ":/special/include", that has the same effect as -I.
-I/special/include.
There are many ways you can change an environment variable. On bash prompt you can do this:
$ export CPATH=/your/source/root
$ g++ /your/source/root/A/code.cpp
$ g++ /your/source/root/A/a/code2.cpp
You can of course add this in your Makefile etc.
gcc -I/path -L/path
-I /path path to include, gcc will find .h files in this path
-L /path contains library files, .a, .so
it's simple, use the "-B" option to add .h files' dir to search path.
E.g. g++ -B /header_file.h your.cpp -o bin/your_command
Headers included with #include <> will be searched in all default directories , but you can also add your own location in the search path with -I command line arg.
I saw your edit you could install your headers in default locations usually
/usr/local/include
libdir/gcc/target/version/include
/usr/target/include
/usr/include
Confirm with compiler docs though.