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.
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
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...
I'm developing a C/C++ library that uses ImageMagick (using/supporting both libMagickCore and libMagick++), for reading and writing image data (not for processing).
Now, I would also like to support IM's GraphicsMagick fork (e.g. using Debian's graphicsmagick-libmagick-dev-compat package).
Unfortunately, the APIs have diverged enough, so that I cannot use one as a drop-in replacement of the other. Since they are still quite similar, I plan to use a number of #ifdefs for the API specific parts.
Now my problem is, that it seems quite complicated to detect which API is actually used via pre-processor directives, right after including the generic header (which is called the same for both variants).
Basically, I'm looking for something like a #define (provided by the IM/GM headers) that can be used to tell the two APIs apart. Something like:
#include <Magick++.h>
#ifdef GRAPHICSMAGIC_DEFINE
// GM-specific code
#else
// IM-specific code
#endif
or, for the C-API:
#include <magick/MagickCore.h>
#ifdef GRAPHICSMAGIC_DEFINE2
/* GM-specific code */
#else
/* IM-specific code */
#endif
Ideas?
Autoconf, or CMake.
Really - there's no simpler way around it, but you need to package your solution with something that will ask the system what library is present, and will then generate config.h with the correct pre-processor definitions.
The difference between GraphicsMagick & ImageMagick seem simple enough to do something clever, BUT now that we're a year into the release of IM 7, we now need to check which version & adjust definitions as needed. For example
// IM 6
#include <magick/MagickCore.h>
// IM 7
#include <MagickCore/MagickCore.h>
I would suggest reviewing existing m4 scripts used by other projects available online.
So back to the original question, the generic include headers my look something like this... (and I quote from Imagick library, but can be expanded to cover GM)
#if defined (IM_MAGICKWAND_HEADER_STYLE_SEVEN)
# include <MagickWand/MagickWand.h>
#elif defined (IM_MAGICKWAND_HEADER_STYLE_OLD)
# include <wand/magick-wand.h>
#else
# include <wand/MagickWand.h>
#endif
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.
This isn't really clearly documented, but a shallow search reveals that RIM's RAPC compiler does support preprocessor statements (with some project file modification).
We've been using the simple #ifdef, #else, and #endif directives for quite some time now, as supporting platforms 4.1 through 4.7 with one code base is nearly impossible without them, but I began wondering recently if there are other supported directives which aren't quite as well documented; something akin to C's #elif for example, or even rudimentary equivalency directives?
Here's a complete listing of commands for the RAPC preprocessor. The preprocessor's not very robust, but that's on purpose.
//#preprocess - Used to specify that the file should be preprocessed. It must be the first line of the file.
//#implicit tag - This needs to be on the second line of the file. If tag is part of the command line, then the whole file should be compiled. If not, then it should be excluded.
Then there's the //#ifdef tag ... #else ... #endif and the //#ifndef tag ... #else ... #endif directives that you mentioned.
Also note, there is no nesting of preprocessed blocks and no macros.
RIM Help Center Doc:
http://docs.blackberry.com/en/developers/deliverables/21065/Specifying_preprocessor_directives_657636_11.jsp