'ANImageBitmapRep.h' file not found in cocoa pods installation about rscolorpicker HOT 16 CLOSED

Thank you for the detailed debugging, but I'm not so sure what to do with it as a "user" of CocoaPods.

We define the source in our podspec as:

s.source_files = 'RSColorPicker/ColorPickerClasses/**/*.{h,m}'

That still seems accurate. I'll make a test project and see what I can figure out.

from rscolorpicker.

I just made an empty single-view iPhone project and placed pod 'RSColorPicker', :head in my Podfile. After a pod install and adding a RSColorPickerView subview to the storyboard, the project runs without any problems.

It also works with pod 'RSColorPicker', :git => 'https://github.com/RSully/RSColorPicker.git'

from rscolorpicker.

Thanks for looking into this issue. It appears that this issue appears to be outside the realm of RSColorPicker. I will investigate further. What versions of pod, gem, ruby and Xcode are you using?
I used
ruby 2.0.0p247 (2013-06-27 revision 41674) [universal.x86_64-darwin13]
gem 2.2.2
pod 0.29.0

from rscolorpicker.

> ruby -v
ruby 2.1.1p76 (2014-02-24 revision 45161) [x86_64-darwin13.0]
> gem -v
2.2.2
> pod --version
0.29.0

Xcode 5.0.2

from rscolorpicker.

I am going to close this, but feel free to continue discussion here.

from rscolorpicker.

Hi again. I investigated this issue further and I think I have a handle on what is happening. Builds within the client project are failing because not all of the include files can be found. There are a number of ways to work around this issue in the .podspec file.

1. Remove the public_header_files spec. This makes all .h files public.
2. Manually specify that all header files are public.
   s.public_header_files = "RSColorPicker/*/.h"
3. Manually specify all required public header files.
   s.public_header_files = "RSColorPicker/ColorPickerClasses/RSColorPickerView.h", "RSColorPicker/ColorPickerClasses/ANImageBitmapRep/ANImageBitmapRep.h", "RSColorPicker/ColorPickerClasses/ANImageBitmapRep/Compatibility/OSCommonImage.h", "RSColorPicker/ColorPickerClasses/ANImageBitmapRep/CoreGraphics/CGImageContainer.h", "RSColorPicker/ColorPickerClasses/ANImageBitmapRep/Manipulators/BitmapScaleManipulator.h", "RSColorPicker/ColorPickerClasses/ANImageBitmapRep/Manipulators/BitmapContextManipulator.h", "RSColorPicker/ColorPickerClasses/ANImageBitmapRep/BitmapContextRep.h", "RSColorPicker/ColorPickerClasses/ANImageBitmapRep/CoreGraphics/CGContextCreator.h", "RSColorPicker/ColorPickerClasses/ANImageBitmapRep/Manipulators/BitmapCropManipulator.h", "RSColorPicker/ColorPickerClasses/ANImageBitmapRep/Manipulators/BitmapRotationManipulator.h", "RSColorPicker/ColorPickerClasses/ANImageBitmapRep/Manipulators/BitmapDrawManipulator.h", "RSColorPicker/ColorPickerClasses/ANImageBitmapRep/Compatibility/UIImage+ANImageBitmapRep.h"

Since cocoa pods uses a convention over configuration philosophy I chose option # 1.

FYI - I filed a bug on the -isystem and -iquote issues.

from rscolorpicker.

Could you send me a link to the bug report?

I'm still having a hard time trying to grasp why either is necessary - why does it work when I create a new test project, but not for you? That is what I'd like to get to the bottom of. If you could make a project that fails (send a download link) then I could help debug it. If there is private data/info, feel free to email it using the address on my GitHub profile page.

from rscolorpicker.

Also, my understanding is that public_header_files signifies which headers are apart of the public API, which for my project is only the current file listed. As I try to follow semver this is important to me.

from rscolorpicker.

Here is the link to the issue I submitted about the system and -quote issues. CocoaPods/CocoaPods#1862
My current thinking is that these these bugs are tangental to the problems with RSColorPicker.

My project can find the public header file RSColorPickerView.h. The problems arise when RSColorPickerView.h imports ANImageBitmapRep.h. This file is not found. It and all of the files it causes to be imported are not in the Pods/RSColorPicker/Headers directory which is the directory that is visible to all of the projects outside of the Pods.

One reason that our results differ may be that you are building your test program in the Pods area. I build my application outside the Pods area. My workflow is

1. Create a new project in Xcode.
2. Close the project
3. Create a Podfile that requests RSColorPicker.
4. Run "pod install" from the command line
5. Open the .xcworkspace file
6. Select Product->Clean
7. Then build as usual.

I am not experiencing this issue with any of the other pods I am using (AFNetworking ...). I am probably just lucky.

Since your public header imports another header file, wouldn't the imported header file be considered public as well?

Does your integration testing include testing your library as a pod as well as embedded source?

I will create a failing project for you later this weekend. Hopefully I'll get to it by Sunday.

from rscolorpicker.

Hmm.. the workflow for the test project I created was pretty much the same as what you're describing.

I think a failing test project would be the best bet, let me know when you're ready with it.

Regarding the public-API/designated-headers: there are 2 things I am thinking. (a) I could see if we can move the #import from the header file to the implementation, and use things like @class to get around any issues, because (b) I consider RSColorPicker public API as what is defined in RSColorPickerView.h - any dependencies I use (like the bitmap rep) aren't what I am defining as public API; I think I see your point.

from rscolorpicker.

I have created an Xcode project that exhibits the failures I have been encountering. It is based on the sample RSColorPicker code. I will be sending you a bzip2'ed tar file via email. I chose this method rather than a git so you will be able to see the exact same state (both source files and derived files.) that I am seeing.

The code in its current state will fail to compile due to missing include files. The pod was installed with the released 0.8.3 RSColorPicker.podspec file.

The code will compile correctly if the following steps are followed.

1. Close the workspace in Xcode.
2. Comment out (# is the ruby comment char) the public_header_files line in the pod spec file.
   3 Run "pod install"
3. Open the workspace, clean and build.

I just realized that the Podfile does not specify a version for RSColorPicker. In my environment this defaults to 0.8.3. You may need to to change this if you are working on newer versions.

from rscolorpicker.

I got the project, thanks.

I think the best bet is to go with what I said before: move the includes from the .h to the .m within RSColorPicker. What do you think about this?

from rscolorpicker.

I agree. I don't understand why the ANImageBitmapRep.h file is imported in the in public header file since none of the public interfaces require it.

from rscolorpicker.

@bromoab could you try it now by forcing CocoaPods to use the master branch?

from rscolorpicker.

I tried it on my app and it now works. However it failed in the Tester app I built for you because this app uses the RSBrightnessSlider RSOpacitySlider classes which don't appear to be modified to move the includes into the implementation files. I consider this issue slain.

from rscolorpicker.

Awesome! I'm not 100% ready to tag another release yet, but I'll keep this bug in mind and try to do it sooner than later.

from rscolorpicker.