Is there anyway to restrict by using pre-processing directives to prevent a project from compiling when both the Release and Debug symbols are defined?
Please let me know.
Assuming C/C++:
#if defined (Debug) && defined (Release)
#error Debug and Release are both defined !
#endif
See here. According to this it works in VC++ as well.
Related
In my schema, I have specified Release as the build type:
In my code I have some checks to see if it's in DEBUG or RELEASE. However it always hits the DEBUG (line 125 in the example below):
Do you know what I might be missing when I build for release so it stops hitting the DEBUG flags?
Conditional compilation like this does not depend on the Build Configuration but the presence of the DEBUG flag within that configuration.
Go to your project's build settings and search for 'flag'. Look under 'Swift Compiler - Custom Flags' and then 'Active Compilation Conditions': each build configuration is then listed and the flag DEBUG should be present where you want your debug code to appear but absent where you do not.
I just update my project to Xcode 8 but don't know why my xcode console is flood with Dsymulti warning message.
while processing /Volumes/Data/OneDrive/Singpost/Esam/Vic/Version1/SAM/eSAM/SAMKiosk/Classes/Libs/NETS/libNETS.a(NETS.o):
warning: /Users/Chetas/Library/Developer/Xcode/DerivedData/ModuleCache/9CPWN0R8YQPE/Foundation-A3SOD99KJ0S9.pcm: No such file or directory
note: Linking a static library that was built with -gmodules, but the module cache was not found. Redistributable static libraries should never be built with module debugging enabled. The debug experience will be degraded due to incomplete debug information.
while processing /Volumes/Data/OneDrive/Singpost/Esam/Vic/Version1/SAM/eSAM/SAMKiosk/Classes/Libs/NETS/libNETS.a(NETS.o):
warning: /Users/Chetas/Library/Developer/Xcode/DerivedData/ModuleCache/9CPWN0R8YQPE/ObjectiveC-2CD0WTQVXITO7.pcm: No such file or directory
while processing /Volumes/Data/OneDrive/Singpost/Esam/Vic/Version1/SAM/eSAM/SAMKiosk/Classes/Libs/NETS/libNETS.a(NETS.o):
warning: /Users/Chetas/Library/Developer/Xcode/DerivedData/ModuleCache/9CPWN0R8YQPE/CoreFoundation-10I2D2XL7L7X9.pcm: No such file or directory
My project still can build successfully. Any one know how can we deal with these warnings?
For me, I could solve setting in Build Settings
Generate Debug Symbols = No
I've gone through the various solutions of compiling libical v1.0 for armv7, however the latest libical library available on github seems to have moved to cmake:
https://github.com/libical/libical
Can someone please guide me as to what I should be doing to get this to compile for iOS and Mac (one fat static library)? I've been able to compile it for the Mac but don't know how to do the same for armv7 and arm64. Thanks!
I tried everything from ios-toolchain for cmake to writing a build script myself. Nothing worked. In the end it turned out to be simple. Simply run cmake and compile libical on a 64-bit Mac. Then take all the produced code from under the "src" directory and add that straight to your iOS project. Then, replace #include with #include "config.h" globally and disable ICU support. Add a preprocessor macro to your build settings to include the generated config.h
I added Facebook Tweaks to my project via CocoaPods and now I want to share the app with some tester via TestFlight. By default, Tweaks is deactivated in the Release build (which is used when archiving for distribution), so I did the following:
created a new scheme "MyApp TestFlight" by copying my original scheme
Added a Build configuration in the project info screen, called "TestFlight" (in addition to the preconfigured "Debug" and "Release". When asked which configuration I wanted to inherit settings from I used the "Release" configuration.
In the "MyApp Testflight" scheme I set the build configuration to use for "Archive" to be "TestFlight".
In the preprocessor macros I defined different values for the macro FB_TWEAK_ENABLED which is used by the Facebook Tweaks Library to enable and disable it's usage. Since I surely don't want Tweaks enabled in the Release configuration (e.g. for the App Store) but I do want to be able to distribute an app with Tweaks enabled via TestFlight, I activated Tweaks in the Debug and TestFlight configurations, but not in the Release configuration.
I verified that activating and deactivating Tweaks works by switching the FB_TWEAK_ENABLED between 0 and 1 in the Debug configuration.
So far everything works, I can activate an deactivate Tweaks using my preprocessor constant. I also verified, that using the different schemes to run changes the preprocessor constants as expected.
So I can successfully run the app with and without Tweaks enabled. But when I try to archive it, it fails with a linker error:
Undefined symbols for architecture armv7:
"__FBTweakIdentifier", referenced from:
___30-[SUPConfirmPaymentView setup]_block_invoke_2 in SUPConfirmPaymentView.o
___30-[SUPConfirmPaymentView setup]_block_invoke_254 in SUPConfirmPaymentView.o
___30-[SUPConfirmPaymentView setup]_block_invoke_277 in SUPConfirmPaymentView.o
___30-[SUPConfirmPaymentView setup]_block_invoke_2102 in SUPConfirmPaymentView.o
___30-[SUPConfirmPaymentView setup]_block_invoke_2125 in SUPConfirmPaymentView.o
___30-[SUPConfirmPaymentView setup]_block_invoke_2150 in SUPConfirmPaymentView.o
___30-[SUPConfirmPaymentView setup]_block_invoke_2171 in SUPConfirmPaymentView.o
...
ld: symbol(s) not found for architecture armv7
clang: error: linker command failed with exit code 1 (use -v to see invocation)
There are more errors like this for armv7s and arm64.
But my project, as well as the target, as well as the libraries in the Pods project and the Pods project itself all have Architctures and Valid Architectures set to "arm64 armv7 armv7s".
For the record: My SUPConfirmPaymentView setup method does a lot of calls like this:
// setup animation constants
FBTweakBind(self, beatEnlargementFactor, #"Confirm Payment View", #"Beat Animation", #"scale factor", 1.1, 1.0, 3.0);
But I don't think that's the problem as it works in the debug builds and I guess it's just the first place the linker notices something is wrong.
So what does work:
Run on simulator or device using DEBUG configuration which fas FB_TWEAK_ENABLED=1
Run on simulator or device using DEBUG configuration which fas FB_TWEAK_ENABLED=0
Archive using RELASE configuration which fas FB_TWEAK_ENABLED=0
Run on simulator or device using TestFlight configuration which has FB_TWEAK_ENABLED=0
Archive using TestFlight configuration which has FB_TWEAK_ENABLED=0
What doesn't work
Run on simulator or device using TestFlight configuration which has FB_TWEAK_ENABLED=1
Archive using TestFlight configuration which has FB_TWEAK_ENABLED=1
I don't understand why it doesn't work as it should be the same as the Release configuration (I copied it from that) and that does work, except for this one constant. And the debug build using that constant DOES work.
Any ideas what's going wrong?
EDIT:
Thanks to #alloy for pointing to this issue on CocoaPods: https://github.com/CocoaPods/CocoaPods/issues/1934#issuecomment-40132425
It seems to be related.
Therefore I used the following code from the issue discussion:
#if defined(DEBUG) && DEBUG
#warning DEBUG=1
#else
#warning DEBUG=0
#endif
And copied it to SUPConfirmPaymentView.m.
The result is this:
By just pasting the code I already get a wring for Debug=1, which is due to Xcode's continuous compilation (which apparently uses the DEBUG flag).
But when using Archive I get the results above and as far as I understand it, those warning below the Target all result from this one Archive build right? This would mean that the preprocessor (?) passes the .m-file twice, once with DEBUG=1 and once with Debug=0, which would explain the problem.
But this raises two other questions:
Why does it pass the .m file twice, should it just come by once as it's a .m-file (I see why that happens for .h files)
Why is DEBUG=1? Where does that come from?
EDIT2:
I recreated my "TestFlight" target to be a copy of the Debug target, as recommended by #alloy. It still doesn't build, which is likely due to CocoaPods not using the debug configuration.
How can I make it use the debug configuration? #alloy mentioned something about :debug, but I don't know how to use it and didn't find any documentation about it.
My current Podfile looks like this (project excluded):
platform :ios, '7.0'
pod 'AFNetworking', '~> 2.0'
pod 'Tweaks'
How would I use the :debug syntax to make CocoaPods build the Tweaks library in the debug configuration when using it for my 'TestFlight' configuration?
I think you are running into this: https://github.com/CocoaPods/CocoaPods/issues/1934#issuecomment-40132425.
(I’m not going to cross-paste a long answer and all of its context, it’s better if you read the issue on the ticket tracker.)
I want to use the ASSIMP library http://assimp.sourceforge.net in an iOS project. Unfortunately, I'm not very experienced with makefiles and that stuff, so I need some help.
I've downloaded the sources and first I tried to build with make (in the code-subfolder)
In the makefile I've added INCLUDEFLAGS = -I/Lib because my boost header-files are in /Lib/boost
Executing make static succeeds with some warnings. A static library (.a) is generated.
Then I tried to add the .a-file to my xcode-project and specified the assimp-header folder as additional include directory (Other Search Paths). Linking failed with the message that the library has not the right architecture (i386 required for the simulator)
file libassimp.a outputs: "libassimp.a: current ar archive random library"
How can I build the library for the i386 architcture and for arm6 or arm7, whatever I need on an iOS device?
Is it ok to use the boost-headers only or is it better/necessary to build boost as a library? Currently I'm using boost headers only, which should be fine since boost is a header only library?!
There is also a cmake - makefile (CMakeLists.txt). cmake is the recommended way of building the library but I don't have any experience with cmake.
Or another thought: Is it possible to build a library via xcode?
The final result should be a library for i386, arm6 and arm7 architecture.
What shall I do? And how?
Edit:
I've just discovered that there are the following preprocessor checks in the file aiDefines.h:
#if defined(_MSC_VER)
// See http://msdn.microsoft.com/en-us/library/b0084kay.
# if defined(_M_IX86)
# define ASSIMP_BUILD_X86_32BIT_ARCHITECTURE
# elif defined(_M_X64)
# define ASSIMP_BUILD_X86_64BIT_ARCHITECTURE
# elif defined(_M_IA64)
# define ASSIMP_BUILD_IA_64BIT_ARCHITECTURE
# else
# error unknown architecture
# endif
#elif defined(__GNUC__)
// See http://gcc.gnu.org/onlinedocs/cpp/Predefined-Macros.html.
# if defined(__x86_32__) || defined(__i386__)
# define ASSIMP_BUILD_X86_32BIT_ARCHITECTURE
# elif defined(__x86_64__)
# define ASSIMP_BUILD_X86_64BIT_ARCHITECTURE
# elif defined(__ppc__)
# define ASSIMP_BUILD_PPC_32BIT_ARCHITECTURE
# else
# error unknown architecture
# endif
#else
# error unknown compiler
#endif
Does this mean, it is not possible to compile the ASSIMP library for ARM architecture?
I personally don't do any iOS development, but I know that others have successfully compiled Assimp for their iDevices using Xcode. An Xcode 3 project should be included with the distribution, although I don't know if you can use it without further modification.
The architecture preprocessor defines are currently only used for logging output (in code/Importer.cpp), and support for ARM has been added to trunk in the meantime (r919, to be exact).
I also had a few issues getting assimp to work on iOS devices.
Here's what I did in case anyone is also having similar issues - similar to Artur Sampaio's example above, but with a few differences:
get the latest assimp from https://github.com/assimp/assimp, i.e., git clone git://github.com/assimp/assimp.git
cd into the assimp directory and open up CMakeLists.txt. For some reason, the make file couldn't find my glut and gl libs, so I commented out the lines in CMakeLists.txt that referred to making the samples, i.e., the "IF ( BUILD_ASSIMP_SAMPLES)" block of code. There's probably a simple way to point to these, but since I didn't need the samples I just did commented those lines out.
cd to port/iOS/ and then sudo ./build_ios.sh (it takes a few minutes to compile all 3 versions of the lib).
now if you cd to assimp/lib/ios and lipo -info libassimp.a you will see that the library is a fat file with i386, arm6 and arm7 architectures (and will work on both the simulator and the arm6 or arm7 device).
to get it to work in XCode 4.3.2, drag&drop the libassimp.a file into my project (from the finder). You don't have to actually copy it over to your project directory, it doesn't hurt if you do though.
for some reason, a build will still fail unless you explicitly link to the libz dynamic library. Click the main project from the XCode file list, select TARGETS, then click on the Build Settings tab, scroll down to the Linking section, and then add "/usr/lib/libz.dylib" under "Other Linker Flags".
the current version of assimp on github seems to have restructured the code somewhat, and while all of the examples I tested from the assimp website work, they all require different, or at least renamed, header files:
Here I've commented out the previous names of the headers and below are the new names:
//#include <assimp.hpp> // C++ importer interface
//#include <aiScene.h> // Output data structure
//#include <aiPostProcess.h> // Post processing flags
#include "Importer.hpp"
#include "scene.h"
#include "postprocess.h"
After this point I was able to use assimp on my iPad.
Also, you probably want to make sure that you have uninstalled other versions of assimp before doing this (eg from macports or brew).
I found branch where one guy already changed project setting for your needs. https://github.com/blandinw/assimp/tree/ios-xcode46/doc
What I did was:
download version 1090 of the Assimp repo: http://assimp.svn.sourceforge.net/viewvc/assimp/trunk/?pathrev=1090
unzip
cd ~/Downloads/trunk/port/iOS
sudo ./build_ios.sh
(replace ~/Downloads/trunk with the path to the unzipped folder)
wait...
check libs at ~/Downloads/trunk/libs/ios/
hope that works