Trying to figure out how to use BGL from within Objective-C++. Something is amiss. Steps to repro:
New Cocoa Application project.
Rename MyAppDelegate.m to MyAppDelegate.mm
Add #include <boost/shared_ptr.hpp> to MyAppDelegate.mm (works fine, assuming you have your header search paths set right.)
Add #include <boost/graph/adjacency_list.hpp> to MyAppDelegate.mm
Something transitively included by boost/graph/adjacency_list.hpp is colliding with some old Carbon headers that are being transitively imported by the Cocoa headers. Here is the output I see (the first error's worth anyway):
In file included from /Users/me/Documents/Projects/BoostTest/BoostTest/MyAppDelegate.mm:10:
In file included from /Users/me/Documents/Projects/BoostTest/boost/graph/adjacency_list.hpp:33:
In file included from /Users/me/Documents/Projects/BoostTest/boost/graph/graph_traits.hpp:27:
In file included from /Users/me/Documents/Projects/BoostTest/boost/pending/property.hpp:13:
In file included from /Users/me/Documents/Projects/BoostTest/boost/type_traits.hpp:35:
In file included from /Users/me/Documents/Projects/BoostTest/boost/type_traits/has_operator.hpp:12:
In file included from /Users/me/Documents/Projects/BoostTest/boost/type_traits/has_bit_and.hpp:43:
/Users/me/Documents/Projects/BoostTest/boost/type_traits/detail/has_binary_operator.hpp:154:42: error: expected member name or ';' after declaration specifiers
static ::boost::type_traits::yes_type check(has_operator); // this version is preferred when operator exists
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
In file included from /Users/me/Documents/Projects/BoostTest/BoostTest/MyAppDelegate.mm:9:
In file included from /Users/me/Documents/Projects/BoostTest/BoostTest/MyAppDelegate.h:9:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:76:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSURLError.h:12:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:23:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/AE.framework/Headers/AE.h:20:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:115:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/Debugging.h:212:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/AssertMacros.h:1291:28: note: expanded from macro 'check'
#define check(assertion) __Check(assertion)
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/AssertMacros.h:280:5: note: expanded from macro '__Check'
do \
^
If I remove the #import <Cocoa/Cocoa.h> from the project's prefix header, and then #include <boost/graph/adjacency_list.hpp> before including <Cocoa/Cocoa.h> in MyAppDelegate.mm things will compile, but this is sub-optimal/undesirable.
Is there something simple I can do (ideally in the prefix header so I don't have to do this everywhere) to make the Cocoa headers and the BGL headers co-exist peacefully?
Should have googled for epsilon more time before asking. Just after posting this I found this page which explains that adding the following line prior to including the Cocoa headers will do the trick:
#define __ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORES 0
I had tried doing that in my individual MyAppDelegate.mm file, and it didn't work, but that was because of the prefix header. Adding it to the project's prefix header prior to its inclusion of Cocoa/Cocoa.h did the trick.
Related
I'm New to CLion. I have created a project which name is test12 and which file name is avs.c.
I'm Getting an Error of type Undefined reference 'sqrt'
CMakeListsta.txt is :
cmake_minimum_required(VERSION 3.13)
project (test12 C)
set(CMAKE_C_STANDARD 99)
add_executable(test12 avs.c)
What changes should I do to make CMAKELISTS use math.h header in CLion?
It looks like math.his not enabled in CLion, so you need to enable it! Source here.
add #include <math.h>
add target_link_libraries( m) in CMakeLists.txt
The second command allows you to link with libm for the math functions.
Adding this to your makefile! (Check the source I gave you!!)
target_link_libraries(log m)
Is there a way to specify in the Podfile that an xcconfig file should be #included in the the one generated by Cocoapods?
Is there an exposed method/variable for appending this #include or do I need to read the generated xcconfig and regurgitate it with the additional text?
For instance, in the generated Pods-SomeTarget.[configuration].xcconfig, I'd like to see:
#include "my_other_config.xcconfig" //<-- I want this to be inserted
FRAMEWORK_SEARCH_PATHS = $(inherited) "${PODS_ROOT}/Crashlytics" "${PODS_ROOT}/Fabric" "${PODS_ROOT}/Google-Mobile-Ads-SDK/Frameworks" "${PODS_ROOT}/GoogleAds-IMA-iOS-SDK-For-AdMob/GoogleInteractiveMediaAds/GoogleInteractiveMediaAds-GoogleIMA3ForAdMob" "${PODS_ROOT}/NewRelicAgent/NewRelicAgent" "${PODS_ROOT}/TwitterCore/iOS" "${PODS_ROOT}/TwitterKit/iOS"
GCC_PREPROCESSOR_DEFINITIONS = $(inherited) COCOAPODS=1
Include these lines in your debug and release xcconfig files, respectively:
#include "Pods/Target Support Files/Pods-Used/Pods-Used.debug.xcconfig"
#include "Pods/Target Support Files/Pods-Used/Pods-Used.release.xcconfig"
Then click on your project and in the detail navigation bar on the left switch from your current target to your project and select Info at the top. Set the project to use your base/shared config file and Debug/Release to point to your xcconfig files.
I have an Xcode 7.2 project that succeeds when building/running against the local device Product|Build. The main project include a reference to InAppSettingsKit project. When I try Product|Archive the build fails. Any help or suggestions will appreciated.
The main project has a bridging header file to InAppSettingsKit project. The problem seems to be that the header file referenced in the bridging header file is not found.
Bridging Header File
#ifndef Screen_Saver_Killer_InAppSettingsKit_Bridging_Header_h
#define Screen_Saver_Killer_InAppSettingsKit_Bridging_Header_h
#endif
#include <UIKit/UIKit.h>
#import "InAppSettingsKit/IASKViewController.h"
#import "InAppSettingsKit/IASKAppSettingsViewController.h"
#import "InAppSettingsKit/IASKSpecifierValuesViewController.h"
#import "InAppSettingsKit/IASKSpecifier.h"
#import "InAppSettingsKit/IASKSettingsReader.h"
#import <iAd/iAd.h>
As requested, here is the search paths of the main project:
(I noticed InAppSettingsKit.xcodeproj is in red; does that mean anything ?)
My problem was with InAppSettingsKit. Their website says: for Archive builds there's a minor annoyance: To make those work, you'll need to add $(OBJROOT)/UninstalledProducts/include to the HEADER_SEARCH_PATHS
This wasn't quite right either.
I think this is a bug in XCode 7.2 + Swift with Obj-C dependencies when archives are built.
I now know way more about xcode than I ever wanted to.
First you need to go through the install logs to find out where things are being built. On my installation $OBJROOT points to:
/Users/jlongo/Library/Developer/Xcode/DerivedData/PROJECTX-bmyyngijghtekdgqqfnabonhpuxo/Build/Intermediates/ArchiveIntermediates/PROJECTX/IntermediateBuildFilesPath
There I found the header files in the path:
.../IntermediateBuildFilesPath/iphoneos/include/InAppSettingsKit/
So my resolution ended up being (non-recursive)
$(OBJROOT)/UninstalledProducts/iphoneos/include
Interestingly, $(OBJROOT) or other recursive paths shorter than this one did not work.
Also I placed this setting in:
Main Project|**Targets**|Build Settings|Header Search Paths
setting it here will not work:
Main Project|**Project**|Build Settings|Header Search Paths
Can I link to individual obj file using #pragma ? I tried #pragma comment(lib, "disk_file_sink.obj") but it doesn't seem to work. And it works if I specify this file in Linker/Input/Additional Dependencies.
I have the same problem as yours and I look up many website but I do not get the result so I use an another method to resolve this problem.That was I did.
I use the command lib to compact the objs to library. You can use lib /out:xxx.lib one.obj two.obj or lib /out:xxx.lib *.obj. The command can add to project property.
I'm having a problem getting XCode to deal with a particular file structure that I am using or that I wish to use.
I have a set of files in the following form...
Library
Headers
Library
Package1
Header1.h
Header2.h
HeaderN.h
Package2
Header1.h
Header2.h
HeaderN.h
PackageN
Header1.h
Header2.h
HeaderN.h
Source
Package1
Source1.m
Source2.m
SourceN.m
Package2
Source1.m
Source2.m
SourceN.m
Package3
Source1.m
Source2.m
SourceN.m
The include model I want for code outside of this library is...
#import "Library/Package/Header.h"
I want to point XCode at Library/Headers but not at the internal folders. When I add this tree to the project XCode seems to make implicit include paths to every node in the tree.
Client code within the project but outside this tree can do this...
#import "Header.h"
instead of...
#import "Library/Package/Header.h"
I can't seem to find a way to dissallow the non-qualified form.
Any help would be appreciated.
Thanks,
-Roman
You're running up against Xcode's behaviour that it builds a flat-headermap. You can disable this by adding the build setting:
HEADERMAP_INCLUDES_FLAT_ENTRIES_FOR_TARGET_BEING_BUILT=NO
to your project settings.
If you include the headers in files in the project then XCode will always find them without path qualification, as you've discovered. The best solution is to remove the headers from the project and specify "Library/Headers" as a header search path in your project settings. The headers won't show in your project, but they also won't be implicitly found by XCode while compiling, either; client code will have to specify the full path off of "Library/Headers" to get to the header file they want.