Is there a #pragma-like instruction to suppress warnings when building on OSX with Xcode?
I am trying to build my software on OSX with Xcode. The softwre depends on thr SQLite, which I downloaded as a source code and included in my project.
Unfortunately when I build from Xcode it produces a number of Ambigious expansion of macro MAX.
I was told that it is normal from SQLite people, but since that number is huge and it will continue growing I'd like to suppress it to make the log smaller.
I'm on Xcode 9.4 with clang, but I'd appreciate if that would be working on previous versions of Xcode (with possibly gcc).
Related
I have a serious issue getting Xcode 7.3 to compile a Project against Mac SDK 10.7 with LLVM (7+) and C++11. The source of the issue seems to be Xcode or the fact that I'm running OS X 10.11. Some colleagues of mine don't have the same issue compiling the same issue with older Xcode Versions (6). Here is the general setup:
The needed Libraries and Headers are linked with CMake. The Include paths of everything got checked multiple times. The created Xcode Project also seems to be ok, we've compared all important settings (C++ dialect, std library , target, defines etc) against systems where the project does compile.
The actual error comes when compiling vecLib source.It seems to be a set of random error messages I would trace back to the lack of c++ std headers.. Here are a few examples:
Explicite specialization of non-template class 'complex'
Redifinition of complex as different kind of symbol
Did anybody run into similar problems when working with newer Xcodes against older SDKs?
EDIT
Here is some more informations. After checking what was behind the redifinition, I found that for some odd reason, the complex definition that was interfering with the forward declaration in the file comes from /usr/include/c++/4.2.1. I think that the header is outdated or at least not compatible with c++11. I checked again what the compiler used and the lib / language (std=c++11 and stdlib=libc++) where correctly set. I have the strange feeling that the source in user/include isn't supposed to be included but I don't know how to fix it.
EDIT 2
I've checked the standard include paths with cpp -v and got the following list:
/usr/local/include
/Applications/XCode/.../XCodeDefault.xtoolchain/usr/bin/../lib/clang/7.3.0/include
/Applications/XCode/.../XCodeDefault.xtoolchain/usr/include
/usr/include
/System/Library/Frameworks
/Library/Frameworks
The definition of complex in the Xcode toolchain (3rd entry) is the correct one, the definition in /usr/include is the one that seems to be used while compiling, leading to the error messages. The definition of complex uses structs.
What is the issue here? Is the issue that Xcode / Clang or what ever decides to go with usr/include instead of the toolchain include? I've checked the project settings and the compiler output and there was no explicit include of this path.
It seems like AppleClang 7+ and libc++ just doesn't support vecLib from OS X SDK 10.7. I had to go back to Xcode 6 to get it to build.
To be able to compile an Xcode project that contains some inline Intel assembler code in it, I have used the brilliant xcodelegacy by Frédéric Devernay. Using the LLVM GCC 4.2 compiler in Xcode 6, I am now able to compile and debug the application. The build shows only warning errors at this point, no fatal errors.
The assembler code is definitely being compiled, because I can step into it while in the debugger.
However, when you click on a file with the assembler instructions (i.e., _asm { } ), Xcode still shows fatal errors. I assume this is because the analyzer that scans these files (something like the old Code Sense I assume) is not using LLVM GCC 4.2.
I cannot figure out how to prevent these errors. While they do not impact my ability to work on this project, they are a bit annoying since they are not "real." Is there a way to fix this?
Thanks in advance for the help.
Those are just editor problems. Either right-click on the file in Xcode and chose "Open Using External Editor", or open it with another editor (such as TextWrangler).
my problem is that i can't visualize deprecated warning in xcode 4.5. like viewDidUnload or presentModalViewController.
I checked the flag "Warn About Deprecated Functions" and is correct (YES).
I tried to create e new project and copies all files, but i get the same result.
I tried to building with two available compiler LLVM GCC4.2 and Apple LLVM 4.1
The strange thing is that other project has found all deprecated functions correctly.
Any idea?
Thanks
It seems that these warnings are based on your deployment target. (And not the base SDK, which is what I expected.) This seems like a wise choice, since in order to get rid of the warnings, there's a good chance you'll need to use newer methods that didn't exist yet in the older SDK.
So if you want to make sure you're seeing every deprecation warning, select your target in the Targets list, and set the Deployment Target to the latest version. Do a build or choose Analyze from the Product menu, and you'll see all the warnings.
I can't stand XCode, but really love OpenFrameworks, and I know it works on Linux+Win32 so I don't see why it should be XCode dependent. If I need to have XCode installed that's fine, I just don't want to use it at all.
Xcode internally uses gcc/llvm. in fact from the command line you can cd into a directory that contains an openFrameworks project and just type xcodebuild. but this won't allow you to edit the project file and add new source code, etc.
the Linux makefiles could be adapted to work on OSX as well. they already contain a lot of the information necessary about finding the correct source files, library paths etc. however Linux allows us to install many more components as shared system libraries, while on OSX we link most of the libs statically, so a number of extra library paths would need to be added. probably the biggest gotcha is that everything has to be compiled 32 bit, which means passing -arch i386 everywhere, so you can't just install dependant libs using Homebrew or MacPorts. we are in the process of transitioning to 64 bit but there are still some QuickTime calls that require us to stick with 32 bit, mainly around accessing legacy video capture devices that a lot of us still use for computer vision.
like #cdelacroix points out, we only maintain Xcode project files on OSX. this is mainly due to the lack of a decent alternative. there is a version of Code::Blocks for OSX but it is not very well supported, has some issues with native gui rendering and tends to lag behind the other platforms. Xcode is also the easiest way to install a toolchain on OSX so for most users installing Xcode is necessary.
if you do get a makefile based build system working, and would be interested in maintaining it medium to long term, please consider contributing it to the GitHub repository, it would be gladly accepted.
As of March 2013, openFrameworks has official makefile support for compiling the library itself. However, at the time of this writing, the changes haven't yet been merged into the stable release. You'll need to clone the Git repository and switch to the development branch.
git clone https://github.com/openframeworks/openFrameworks
cd openFrameworks && git checkout develop
cd libs/openFrameworksCompiled/project
make
As far as I can tell, we still need to use the unofficial solutions for compiling apps against the library.
You need Xcode, or at least a set of compilers (more information is available here), but otherwise, no, you can edit/work with the code in whatever editor or environment you want.
Here's a link to a makefile which will compile an OpenFrameworks application on OsX:
https://gist.github.com/labe-me/1190981
Place the makefile in the apps' directory and run make. Tested on OsX 10.6, but haven't tried with addons yet.
As #mipadi said, there is no requirement to actually use Xcode, you can do pretty much everything you do in Xcode with make or cake or any of your build system of choice. All you have to do is find the right set of command line options to pass to the usual tools (compiler, linker, strip, etc.), and sometimes the easier way is to... look in the Xcode build window how it is doing stuff (expand the lines with the small button on the right of each line).
For example you can link with your framework of choice with ld -framework Framework -FPathToFramework foo.o or your dynamic library with ld -lLib -LPathToDylib foo.o. You might have to learn about #rpath, #loader_path and install_name_tool to ship a self-contained packaged application.
As for OpenFrameworks, the "requirement" for Xcode is that the authors decided to maintain only Xcode project files. I just looked at how they do it, they ship source code and Xcode project files that build static libraries, so it will be even more simple for you (although you will need to link the library dependencies by hand). You will have to choose between compiling everything from source in your build system (if you want more customization power without touching Xcode), or just produce the 2 static libraries (openFrameworks.a and openFrameworksDebug.a) with Xcode once, then use them in your build system (recommended until you really need continuous customization).
I have a Carbon-based project that compiles on XCode 3, but fails on XCode 4.
It can't seem to find any Carbon or QT functions, even though I've included
and #include
I get lots of errors like this:
No member named 'InitCursor' in the global namespace
I tried re-adding in the Carbon.framework from the System/Library/Frameworks folder
The InitCursor function, along with pretty much everything else in QuickDraw, was removed in Lion. You will need to remove your uses of all removed APIs, and probably replace most of them with more modern replacements.
This is a non-trivial task, but it is necessary if you want to build with modern tools and target current and future versions of Mac OS X.
It's been a long time coming, too; QuickDraw has been deprecated for years.
Much of Carbon is still supported, and you should find that you are not getting errors about those APIs.
You mention Qt; I've heard that there is a Cocoa version of Qt now.