I can build for debugging just fine. I've triple checked that the static library is included in the build phases settings for the project. I've also tried other things like header include paths and such to no avail.
When I try to build an IPA for test flight, I get an error:
#import <MBProgressHUD/MBProgressHUD.h>
I've been able to build an IPA before, but it didn't implement/use the MBProgressHUD static library before.
I can include the the header and code file manually instead of statically linking it, but I prefer to know what's going on here.
Thanks.
PS - I used the "Static Library" instructions given https://github.com/jdg/MBProgressHUD
No. A library contains solely and only object files. Headers are not object files. Headers are not contained in libraries.
In computer science, a static library or statically-linked library is a set of routines, external functions and variables which are resolved in a caller at compile-time and copied into a target application by a compiler, linker, or binder, producing an object file and a stand-alone executable.
Static libraries belong next to their corresponding dynamic libraries, and in accordance with the FHS. Keep in mind that static libraries are usually only needed to build software, not run it.
The /WHOLEARCHIVE option forces the linker to include every object file from either a specified static library, or if no library is specified, from all static libraries specified to the LINK command.
By default Xcode puts the build products into $(BUILD_DIR)/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)
, this equates to build/Release-iphoneos
for instance. This is the folder that the products get built into and where the headers will get copied to.
When we duplicate the Release configuration to say one called "App Store", Xcode now builds into build/App Store-iphoneos
. The problem is, really, that the static libraries are still being built with their Release configuration, into the Release build folder.
Because the App Store config (for me, at least) is only there to easily switch between provisioning profiles, my solution is to change the "Per-configuration Build Products Path" for the App Store config to $(BUILD_DIR)/Release$(EFFECTIVE_PLATFORM_NAME)
so that the App Store config also builds into the Release build folder.
With the help of another SO questions(https://stackoverflow.com/a/10159481/143225) I was able to get the header file to include.
Apparently, the archive build process is somehow different than the debug build process. By adding "$(BUILD_ROOT)/../IntermediateBuildFilesPath/UninstalledProducts"
to the "User Header Search Paths" build setting it built successfully.
I'd still like to understand why this isn't working as I expect it. I have a hunch that the project is built to auto include the header files for debug and release builds, but somehow not for archive builds. This is odd because I thought archive builds inherit from either debug or release settings from Xcode's scheme settings.
Any additional info is welcome.
Daniel Tull's answer will work, but instead of changing the 'Per-configuration Build Products Path', you can update the static library project Configurations to include a 'App Store' configuration or any other named configuration which your app target is building against, which is a duplicate of the Release configuration. This way, the static library will output it's library and headers/include files to the appropriate directory, which will be resolved by the $(BUILD_DIR)/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME) macro used in the 'Per-configuration Build Products Path'; and walllaaaaa...the public library headers can now be resolved properly by Xcode. So to sum it up, if you have an 'App Store' named configuration in your app's target and your linking against a static library which exports headers, make sure the static library project also includes the 'App Store' configuration and you will be one happy camper.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With