Open dreampiggy opened 5 years ago
amorde
commented
5 years ago @dreampiggy including headers in source_files and not including them in either private_header_files nor public_header_files will result in the header being marked as a Project header. Does this solve what you're trying to accomplish?
dreampiggy
commented
5 years ago @amorde No. For this case, actually you means:
ss.source_files = 'Vendors/libheif/libheif/heif_encoder_x265.{h,c,cc}'
ss.public_header_files = "" # nothing
ss.private_header_files = "" # nothingHowever, this can work for local podspec (using :path => require), but does not pass the pod spec lint or pod trunk push, make this pod does not works for public usage.
The 'public_header_files' pattern did not match any file. The 'private_header_files' pattern did not match any file.
My current use case, is that one subspec, only contains Project Headers, no any Public Headers or Private Headers. And with some compile source files.
amorde
commented
5 years ago Why doesn't this work?
ss.source_files = 'Vendors/libheif/libheif/heif_encoder_x265.{h,c,cc}'Any headers within source_files will be Project headers, and there are no public or private headers specified. Or is the issue that you are trying to convert the public_header_files in the 'SDWebImageHEIFCoder/libheif' subspec from public to project?
dreampiggy
commented
5 years ago @amorde This syntax, resolve the Pod Poject to use the subspec's headers as Public Headers, but not Project Headers...I've already try this syntax. And I think this is because of the project header generate rules:
source_files, treate all headers as public headerspublic_headers or private_headers, treated as project headersBy following these rules, there are no way to treate all as project headers. So I think it's better to introduce a new podspec syntax. Or there are one hack way, to let user pass public_headers = "" && private_headers = "" works. But however, current cocoapos-trunk forbid this usage.
Here is the screenshot:
# HEIF Encoding need libx265
s.subspec 'libx265' do |ss|
ss.dependency 'libx265'
ss.dependency 'SDWebImageHEIFCoder/libheif'
ss.source_files = 'Vendors/libheif/libheif/heif_encoder_x265.{h,c,cc}'
ss.preserve_path = 'Vendors'
ss.xcconfig = {
'GCC_PREPROCESSOR_DEFINITIONS' => '$(inherited) HAVE_X265=1',
'HEADER_SEARCH_PATHS' => '$(inherited) ${PODS_ROOT}/SDWebImageHEIFCoder/Vendors/include ${PODS_ROOT}/libx265/source/'
}
end
Code about this: https://github.com/CocoaPods/CocoaPods/blob/1.6.0/lib/cocoapods/installer/xcode/pods_project_generator/pod_target_installer.rb#L715-L723
amorde
commented
5 years ago right, but isn't that because that subspec depends on the 'libheif' subspec which does include it in its public header files?
amorde
commented
5 years ago actually not sure that it is included, it looks like there's a nested folder that isn't in the glob pattern. will take a look
dreampiggy
commented
5 years ago @amorde Sorry to bother. But actually, the folder structure looks like this:
- Vendor
-- include
--- libheif
---- heif.h
---- heif_version.h
-- libheif(Git Submodule, below it's another repo's content)
--- libheif
---- src
----- heif_decoder_libde265.hSo, even I use ss.public_header_files = 'Vendors/include/libheif/*.h',, this could not revolve that heif_decoder_libde265.h to become public header. include folders contains only two exact files.
This issue it's easy to reproduce actually, and does not only effect Subspec. Actually, I can not build a Pod, which does not expose any public headers or private headers (A framework, only contains Project Headers, such as extension/hook only framework).
amorde
commented
5 years ago I am able to reproduce, and I narrowed down the source of this behavior to this code path:
So yes you are right if there are any headers at all, they default to public unless public_header_files or private_header_files are non-empty. This seems like something that can be changed, the logic has stayed the same since it was written 6 years ago. Going to investigate whether we need this behavior or not and possibly make a PR.
Thanks for the report!
amorde
commented
5 years ago In the mean time, you should be able to work around this by adding one of the public header files from the other subspec that libx265 depends on
ss.public_header_files = 'Vendors/include/libheif/*.h'@amorde This does not works...I already point this out in the Issue Description. It's forbidden because of pod trunk push extra rules. Only works for local pod install or pod lib lint.
public_header_files: The pattern includes header files that are not listed in source_file
I think, maybe CocoaPods should better filter these special case ? Do I need to submit a issue report for https://github.com/CocoaPods/cocoapods-trunk ? I think their rules is not so suitable.
wellbranding
commented
5 years ago @dreampiggy Hello, may you check if it is related to our problem? https://github.com/CocoaPods/CocoaPods/issues/8594
xiafan-su
commented
3 years ago So any fix for this issue? It's still there for 1.10.1
Report
What did you do?
I have a Pod, which one subspec should only be imported by another subspec, so itself should not produce any Public Headers. And it can not use Private Headers because the parent spec should import the header files.
The podspec looks like this one:
I've tried any of CocoaPods's podspec syntax, even with some tricks, it can build using
pod install. But with no luck to passpod trunk pushTrick 1: Mark both
public_header_files&&private_header_filesto be empty.Trick 2: Use one dummy headers (or one exist public headers from another subspec) as public headers
What did you expect to happen?
There should be a podspec option project_header_files, to explicitly set the project header. It's not public, not private. Because sometime, you don't want to mark those header files into public for end-user to let them import. It's a common use case in framework author, and Swift author already support this type inside language using
package control attribute.For Objective-C/C/C++, it's already supported by native Xcode project, but can not be done via CocoaPods's DSL. Since CocoaPods DSL is aim to generate Xcode project, it should at least cover this type of usage.
What happened instead?
The above tricks can works on
pod install. And generate the correct Xcode project.However, the
pod trunk pushfailed, because of either one type of error or another error.Trick 1, error:
Trick 2, error:
CocoaPods Environment
Stack
Installation Source
Plugins
Project that demonstrates the issue
You can use this SDWebImageHEIFCoder.podspec, by modifying the contents of
libx265subspec'spublic_header_fileswith empty string, and can works withpod install. But can not passpod trunk push. So current, we expose those dummy headers(heif_decoder_libde265&&heif_encoder_libx265) into public. Actually, those should be project headers, and not visible to end-user.