can't find OHAttributedLabel.h during Archiving #90

minorblend opened this Issue Sep 27, 2012 · 26 comments


None yet

7 participants


Building and running my app project with OHAttributedLabel as sub-project works great. But archiving my app failed with the error says OHAttributedLabel.h can't be found.
Is there any other options to set except User Search Path - mentioned in renewed README -?


I saw this issue too, I'm searching for a way to fix the configuration for it to work in all cases.

Meanwhile, you can replace the User Header Search Path in your application's build settings to the relative path where the OHAttributedLabel's headers are located on your disk (probably something similar to ../OHAttributedLabel for example if the project is next to your application's project)

@AliSoftware AliSoftware added a commit that referenced this issue Sep 27, 2012
@AliSoftware Fixing #90 and Build Paths in project so that inclusion of headers wo…
…rks in all cases.

Note: now headers should be #imported using <OHAttributedLabel/header.h> in the application project to work (this is quite more clean anyway)

Just commited a fix that should make include path more logical and work in all situations.

Note that since this fix, the headers needs to be imported using angle brackets and framework-style, as in #import <OHAttributedLabel/OHAttributedLabel.h>, instead of #import "OHAttributedLabel.h", and then there seems to be no need to set the "User Header Search Path" in your application project anymore.

Let me know if it better work for you (once you changed your #imports to angle brackets style) in all configurations so I can close the issue.


To me, it works well for both building and archiving.
I did unset "User Header Search Path" also.


Great thanks


It is still happening for me, with the latest version.

I added the source folder to the user header search paths and imported the files as normal file import instead of framework to solve it...


Thanks for the feedback @AnoxySoftware !

Can you please help me understand why this does not work for you by giving me some detail?

  • Are you using Xcode4, and which version ?
  • Just to be sure, did you actually add the OHAttributedLabel.xcodeproj project as a sibling project of your app project in a workspace (and not as a subproject of your app's project)?
  • Can you tell me if you have any particular settings for your build ? In particular
    ** Special settings for your project build paths (i.e. if you choose "File" > "Project Settings…" in the menu, do you have anything other than the Xcode default, same if you show the "Advanced" panel from here ?)
    ** Have you overridden some build configuration variables like CONFIGURATION_BUILD_DIR or others and used custom values for those? If so, which one?

Thanks for any information.
I hope I can fix the settings so that my project will be as portable as possible in everyone's possible configurations (as I use the same system / configuration settings for all my other libraries to ease their integration as much as possible for the user)!



I'm using Xcode 4.5.1 on OSX 10.7.5
Well, the foders settings are a bit different. So my project's folder is DocumentsDir\Project\Project\Classes
However my xcodeproj is located in: DocumentsDir\Project\project.xcodeproj
OHAttributed label was cloned from git and located in DocumentsDir\OHAttributedLabel

So the xcodeproj, are siblings, but the classes I'm referring to the library not.

There are not custom settings or overriders.



Thanks I will investigate based on this.

But my question regarding projects being siblings was related to the project integration in Xcode, not in the Finder

  • Is the OHAttributedLabel project included as a subproject of your application project, similar to what you see in this capture for example (not the indentation of the subprojects in the Navigator) ?
  • Or is OHAttributedLabel included as a sibling project in your workspace, as in this capture ?

The preferred way in Xcode 4 is using a workspace that includes all the projects as sibling projects (2nd case). If you included OHAttributedLabel as a subproject (as in case 1) I guess that this may explain the differences in configuration.


I misunderstood.
I actually placed the OHAttributedLabel as a subproject inside the "Frameworks" folder in xCode.


Ok so that probably explains the difference.

Just to confirm the origin of the problem, could you try by adding it as a sibling project in your workspace instead of a subproject of your app project, as recommended in the README, an tell me if this works with this configuration?

Thanks for the feedback.

TimE90 commented Oct 11, 2012

Same probleme here. I'm using OHAttributedLabel with RestKit, SDWebImage & GPUImage.

My header search paths are:
"$(BUILT_PRODUCTS_DIR)/../../Headers" (recursive)

I adde OHAttributed in the following way:

  • right click on my project -> add files -> choose OHAttributedLabel.xcodeproj
  • Target - build phases - add libOHAttributedLabel.a & CoreText.framework
  • import with #import <OHAttributedLabel/OHAttributedLabel.h>

When running in simulator or on device all works fine. When trying to archiving I'm getting the error message "'OHAttributedLabel/OHAttributedLabel.h' file not found"

What to do?

TimE90 commented Oct 11, 2012

Sibling project in workspace:

Both doesn't work when trying to archive.

Can you help please?

Thanks a lot..

TimE90 commented Oct 11, 2012

Maybe this helps you: when I edit my schemes and set the build configuration for "Archive" to "Debug" it works.

I can't find a solution for this... :(


So the conclusion, as explained by @AnoxySoftware is that :

  • Either you add the OHAttributedLabel project as a sibling project in the workspace of your application project, as suggested in the README, and in such case it will work as expected
  • Or you add the OHAttributedLabel project as a subproject of your application project, in that case the explanation I give in my README won't match and you will need to add the path to the OHAttributedLabel headers to your HEADER_SEARCH_PATH setting of your application (as you usually do with other libraries) to make it compile

@TimE90 : did you actually try to add the path to the headers in your HEADER_SEARCH_PATH or your USER_HEADER_SEARCH_PATH setting of your app (as suggested above, as explained by @AnoxySoftware and I you probably did for the other libraries/projects your are including in your app)? This would normally solve the issue as explained.

It is quite strange that it works when you change the configuration to Debug in Archive scheme but does not work in Release Archive. I tried this configuration both on my personal Mac and the ones at work and it worked even for Release Archive when adding the project as a sibling in the workspace. Anyway, same questions as for @AnoxySoftware (version, custom build directories settings, etc) to help me understand the differences in our configurations.

Also, where did the OHAttributedLabel headers gets installed when you archive your product? It should be in one subdirectory of the "ArchiveIntermediates" DerivedData's directory
Are you sure you have kept the "SKIP_INSTALL" setting to NO for the lib in Release config, so that the headers are "installed" / copied in the ArchiveIntermediates subdirectory and that the archived app can refer to them using the correct relative path?

Anyway, whatever the answers and your configuration anyway all this how-to in the README was aimed to avoid you to add the relative path of the headers to your USER_HEADER_SEARCH_PATH. But if the compiler have trouble finding the headers anyway, simply adding their path in the USER_HEADER_SEARCH_PATH as you usually do when adding an external lib should solve this compilation issue of your app.

TimE90 commented Oct 12, 2012

No.. I don't get it to work..

I added as a sibling project. I added relative path to "HEADER_SEARCH_PATH" and to "USER_HEADER_SEARCH_PATH". The "SKIP_INSTALL" is set to "NO" (Debug & Release).

I can't explain this behavior. Do you have Skype? Maybe I can do a screen share and you can look what's wrong?

Best Regards & thanks a lot!

TimE90 commented Oct 12, 2012

If I use the "Release" config it builds just fine.
But when using the "AdHoc Config" (duplicated from Release) I'll get the error..

Lascorbe commented Nov 5, 2012

I'm getting this warning and i've got the project as sibling in my workspace

Lascorbe commented Nov 5, 2012

Same Error as TimE90. Archived in Release no problem, Archived in a Release duplicate (Distribution) didn't work.

Compile for debug it's working too.


Yes this is because the header files are searched in the folder corresponding to the configuration the project was built with. If your application uses a "Distrib" configuration, the project will try to find the headers in "Distrib-iphoneos" whereas the OHAttributedLabel project has only "Release" and "Debug" configurations :

  • the libOHAttributedLabel and its headers will be built into $"{BUILD_DIR}/Release-iphoneos" because the OHAttributedLabel project will be archived using its own "Release" configuration
  • your application will be built into "${BUILD_DIR}/Distrib-iphoneos" because your application project is archived using your own "Distrib" configuration

And thus they will be built in two different subfolders and the application files won't find the OHAttributedLabel headers automagically.

So in case you have a special configuration other than Debug or Release, you will have to specify the path to the version (Debug or Release) of OHAttributedLabel you need to search, for each configuration of your Application:

  • In your "Header Search Path" setting of your application project, add "$(BUILD_DIR)/Debug$(EFFECTIVE_PLATFORM_NAME)/include" for all the configurations, except for the configuration you use for Archiving where you should specify "$(BUILD_DIR)/Release$(EFFECTIVE_PLATFORM_NAME)/include" (because the "Archive" action generate the "Release" version of OHAttributedLabel library and headers and library are produced here instead).
  • In your "Library Search Path" setting of your application project, add "$(BUILD_DIR)/Debug$(EFFECTIVE_PLATFORM_NAME)" for all the configurations, except for the configuration you use for Archiving where you should specify "$(BUILD_DIR)/Release$(EFFECTIVE_PLATFORM_NAME)" (because the "Archive" action generate the "Release" version of OHAttributedLabel library and headers and library are produced here instead).

Note: don't forget the quotes around the above settings.

These values are used by Xcode by default if your configuration names are the same (that's why you don't need to add these values if your configuration names in your application project matches the ones in OHAttributedLabel project namely Debug and Release), but you need to specify them if you use different configuration names.


I did all that and it still does not work. I ended up using an older version I found :(.


What solution did you try what error did you get? Can't help w/o more info…

Did you try setting the header search path to the source path directly as one usually do when linking with external library?


I did set header and library path and included the project in the work space (not as subproject), and linked both frameworks. I tried some different combinations after that, but I could not make it work, never finds the <../..>.


I meant: did you set the header path to point to the original headers (instead of the path to where they are installed/copied after compilation) ?

Try setting your Header Search Path to the (relative) path to the folder where you have the OHAttributedLabel source code (and where the original header files are), instead of setting it to the path where they are installed after compilation.


I already had that because it was in a folder together with other frameworks I use


Of course when you use that kind of Header Search Path, you try #import using quotes #import "OHAttributedLabel.h" and not square braces, right?

To be clear:

  • Either you use the standard "Debug" and "Release" configurations in your application project and didn't rename or create any different configuration, in that case you can use square brackets for your imports and the "Header Search Path" shouldn't need to be specified as Xcode will search automatically such imports in the installation directory. That is the configuration I recommand in the README to simplify the integration, in the classic case when the users don't change their configuration names
  • Or you have issues when importing your headers (either because you have a configuration with a different name than "Release" for Archiving and "Debug" for all other cases, or you have tweeked your Xcode configuration), in that case you can:
    1. Specify manually the Header Search Path to point to the installation directory of OHAttributedLabel for each of your different configurations (because you won't use the standard Debug/Release configurations and so Xcode won't find it itself), and continue using square brackets in your #import <framework/header.h>
    2. Or manually specify the Header Search Path to point to the original headers directory (the directory where you have saved the OHAttributedLabel source code on your disk), and thus use quoted #import "header.h". That is the way most other frameworks generally do, forcing you to specify the path to their sources manually.
@AliSoftware AliSoftware added a commit that referenced this issue Nov 18, 2012
@AliSoftware Removing Installation & Install Path ; back to importing quoted heade…
…rs (and not square brackets headers).

This has the disadvantage of forcing the user to add the path to the "Header Search Paths" in his own project's Build Settings, but is more classic and will avoid issues described in #90

If you have different build configurations in your application, for example in my project I have Debug, Release, Enterprise. Add same Configuration to OHAttributedLabel project. That fix my issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment