I'm using C++Builder. I want to include a header file that is located in a separate folder from my project.
I tried to add the folder to the search path, and include the file in my project:
#include "GXWARE32\Include\gxutils.h"
but when I compile I have some errors in the file included
So, I tried to add all subfolders to the search path, and it works with a small folder but not with a big one.
According to the error log, maybe you missed some header file that gxutils.h relies on.
Without code, we can only guess... some libs need a specific #include order... some libs have hard-coded relative paths and by moving them you broke that... Some libs also need configuration macros defined before #include.
From the errors, you have #include'd some file more than once (and it's not protected by a header guard, like #pragma once or #ifndef file_id #define file_id ... #endif macros) and you are missing a previous #include for some datatype used.
Open the gxutils.h file and look around line 143 for the missing datatype. In the IDE, during compilation the cursor usually stops on the stuff directly. Then just search the files in your lib for the datatype, so you know what file to #include before...
All of these might happen sometimes if you include the wrong file... some libs need to include cpp instead of h...
Adding search paths will not do anything as the compiler is not complaining about files not found...
Related
Coc in Neovim seems to be unable to see #include <avr/io.h> since I'm guessing that it's include path isn't known by coc. How can I allow coc to see this include path?
A solution was found to be the following:
In the root of your project directory (the base of compilation) add a file called compile_flags.txt.
To the compile_flags.txt file, for the AVR includes, add -I/usr/avr/include.
NOTE: The compile_flags.txt file only accepts a single argument per line, so the actual contents of this file should be
-I
/usr/avr/include
References:
JSON Compilation Database Format Specification
In VS2019, when I have the possibility to include a class, Intellisense only suggests includes with angled brackets (<>). But in most cases I want quote includes ("").
Is there a way to customize it/ let Intellisense suggest both?
Actually, VS does not have such option to automatically switch to realize your requirements. I think this behavior depends on how you reference the header file into the project. So you have to change the way which you import these header files.
Note: <> searches the header files under include directories or additional include directories
while "" searches the header files under your project folder first and then search under include directories or additional include directories.
So the solution is that:
Please remove the path of these header files under include directories and additional include directories.
Then, right-click on the Header Files folder of your c++ project-->Add-->Existing Item to add these header files into your project.
Then, you can see that Intellisense will recommend "" rather than <>.
====================================================
This is my test result:
I have a header file called header.h and I configured its path into additional include directories, and when I call its variable, you can see:
If I removed the path from additional include directories and add it into the Header Files folder.
I have a library that uses the mysql library (libmysqlclient) on linux that I'm porting to windows, but I seem to run into a "problem" with where the header files are located. Under linux the headers are located under /usr/include/mysql (at least for Debian) so with standard include path they would be included as:
#include <mysql/mysql.h>
However when installed the library under windows the main header seem to be located at c:\Program Files\MySQL\MySQL Connector C 6.1\include\mysql.h which would require it to be included as:
#include <mysql.h>
I need to build it for iOS as well, but at this moment I don't know where the header files will be located there.
What is the normal way to solve this? Should I add /usr/include/mysql to the include path under linux? Wouldn't that open up for higher probability of header name collisions?
You can determine which platform you're running on by checking for a predefined symbol. There are a few lists of such macros floating around; here's one:
http://nadeausoftware.com/articles/2012/01/c_c_tip_how_use_compiler_predefined_macros_detect_operating_system
Then, you can #include a different path depending on the platform:
#if defined(_WIN32) || defined(_WIN64)
# include <mysql.h>
#elif defined(__linux)
# include <mysql/mysql.h>
#elif defined(__APPLE__)
# include <whatever path works on iOS>
#else
# error Unrecognized platform.
#endif
If you need to do this in more than one place, then put it into one of your own include files, and #include that, which will then #include the correct mysql.h in turn.
The other option, as you've already suggested, is to set your include path on each platform so that #include <mysql.h> works. Which one you use is a matter of taste.
I am new to HLSL and in all of the tutorials I found there always seems to be a #include "Fxaa3_11.fxh" in each of them. I include this file and then it also makes a reference to another header file #include "Fxaa3_11.h" and as it goes I also include this file into my content pipeline and still gives me an error X1507: failed to open source file:... whichever way I go.
Is there any way to make a clean, single FXAA.fx file without enabling all this mess of external files?
If you want to compile your shader on the fly , you can use this function
Most important part when using includes is to provide a CompilerIncludeHandler ,include resolves are not automatically done for you (which is a good thing).
You override the open method, then read the include path from the parameters and return the content as a string.
If you just want to have if processed in content manager, Easiest way is probably just to copy paste the content of those header files in the main shader file (where the include is), and delete the include statement. Bit ugly but pretty simple.
Inspecting an archived app, I can see the full path listed for a few source code files in the app binary. Not all source code files are listed.
strings - the_binary_app | grep "\.m"
reveals
/Users/bbarnhart/myPath/myPath/App/path/path/SourceCodeFile.m
as well as a few others. I can not determine how the full paths for a few source code files are embedded in the app binary. I would like to remove them. Any ideas? Is this a build setting or is the project file slightly corrupted?
Some belong to a lib and others are files that belong to the project.
The __FILE__ macro expands to full path to the current file. This is one likely way you might be getting the paths into your executable. For example, the expansion of the assert macro includes the __FILE__ macro.
Look at the output of your strings | grep pipeline. For each of those files, go into your project in Xcode and open that file. Then go to the Related Files doodad and choose “Preprocess”:
Then search through the preprocessor output for the file's path. You will find lots of false positives, because there will be lots of # line number/path directives. You can ignore these, because they only produce debug output, which is not included in your executable file (unless you've done something weird with your build settings). You might find it faster to save the preprocessor output to a file, then open that file and pipe it through grep or use a regexp search/replace to delete all lines starting with #.
Find the other instances where your path appears as a string constant. For example, if you used the assert macro, you will find something like this:
(__builtin_expect(!(argc > 0), 0) ? __assert_rtn(__func__, "/Volumes/b/Users/mayoff/TestProjects/textViewChanged/textViewChanged/main.m", 16, "argc > 0") : (void)0);
That's a case where the path will end up embedded in your executable.
If that doesn't find all the places where you're embedding your path, try selecting “Assembly” from the Related Files doodad. The assembly will be full of comments containing your path; everything after # is a comment in the assembly output, so ignore those.
You will also see your paths in .file directives. I believe these only produce debug symbol output, which doesn't go into your executable, so you can ignore those too.
You will also see your paths in .asciz directives shortly after .section DWARF,... directives. This is more debug symbol stuff that you can ignore.
Look for the remaining cases where your path appears in the assembly output. You need to figure out how to eliminate these cases. How you do that will depend on the context in which the paths appear, so if you need more help, update your question with what you find.
Sounds like your code contains the __FILE__ macro somewhere.