Feature Request
I created a podspec where the folder structure has depth, not all headers exist in the same directory but in lots of different directories.
I want to be able to keep the folder structure I have instead of it flattening out.
After I install my podspec all the headers flatten out and the podspec fails to build because my import statements still reference the more complete paths. There seems to be a lot of stackoverflow articles on this back in 2014 but none of them have a conclusive answer.
Maybe :preserve_pod_file_structure is what you are looking for?
Can you try adding this to your Podfile:
install! 'cocoapods',
: preserve_pod_file_structure => true
You can take a look at the install! Syntax to see other options.
Maybe
:preserve_pod_file_structureis what you are looking for?Can you try adding this to your Podfile:
install! 'cocoapods', : preserve_pod_file_structure => trueYou can take a look at the
install!Syntax to see other options.
@mfiebig If I want to use the preserve_pod_file_structure feature, how do I configure my podspec file? I tried to use this feature in existing projects, but nothing changed.
It's a change within your Podfile not the podspec of your Pod.
See this example:
source 'https://github.com/CocoaPods/Specs.git'
install! 'cocoapods',
:preserve_pod_file_structure => true
platform :ios, '10.0'
target 'Sample' do
pod 'AFNetworking', '~> 3.1'
end
Does this work for you?
The only case I can imagine, where this would not work is, when you use the actual podspec and app_spec to generate the project.
This change to my test Podfile seems to keep the folder structure of my pods. But this also modifies the structure of pods like Realm.
@mfiebig Is there a way to only keep the structure of my pods without touching other pods so as to not break them?
If there is not a way to only keep the file structure of my podspecs from within the Podfile is it possible that adding in that flag will not break any other pods, such as Realm, which are not designed to use preserve_pod_file_structure?
You could add them as development pods (:path => ...) if that鈥檚 an option. Development pods keep their folder structure.
What do you want to achieve with the groups? Maybe there is something available for your problem instead of your proposed feature?
@mfiebig
Basically what I want to achieve is I am making a podspec and I want to keep the folder structure in the podspec so users can see which headers are in which folder. Since this is a release pod I wouldn't like to instruct users to install it as a development pod.
So if in my project which will be podded I have foo/bar/header.h I want the user to see that it is in foo/bar directory when they install my pod.
Right now when I install my podspec it flattens everything, so header.h which was in foo/bar/ is now just in that flat repository. I would like it to still be in foo/bar/
Ok I get it, and you want that feature for users of the pod not for further development of your pod, right?
So why would consumers be interested in the structure? If they are, they could adopt the available syntax in their Podfile?
I guess the internal structure of any pod is non relevant for the pod itself, some users might be interested, hence the user defined syntax.
I guess adding the feature should be a manageable task. Maybe a core member can answer if it aligns with in the interest of cocoapods?
@mfiebig Yes for users of the pod. Consumers would be interested in how the different headers are arranged so they can more clearly see which headers do what (if I have a graphics directory and a math directory in my pod the users know headers in graphics will deal with UI and headers in math will deal with math).
It's more for informational purposes.
If nothing is available to accomplish that would the only options be to either accept a flat directory or to create subspecs and use header_mappings_dir in each of the subspecs to force some folder structure? Where each subspec is a folder (like math or graphics)?
To be specific - the project I am doing this for is the pod of EarlGrey2. If you notice we have CommonLib and TestLib folders so that the user knows what files to use for what. I would like the user to see that CommonLib/TestLib separation after they install the pod instead of just having all those headers combined in the base directory.
Podspecs support header_mappings_dir to control the behavior of flattening headers, and header_dir to control the name of the directory which will contain the headers (defaults to the Pod name).
Do these two attributes help with what you're trying to accomplish?
They help somewhat. The problem is with those you will have to define every single subdirectory manually, i.e. you need a header_dir and header_mappings_dir for every single folder. In a large project this is not ideal. Ideally there would be a single line flag that you can just put in the podspec to preserve all paths.
@brettfazio I get what you would like to do. Maybe @amorde could tell us if this would be an fitting addition to cocoa pods?
For me, it looks like an appropriate documentation could be an alternative (maybe better?) way to do this? Personally I like to rely on docsets (with the awesome dash app) as a source how to do things. While implementing, code comments help to understand things. If users misuse API, maybe cross referencing and "do not ..." comments can help.
Anyway, if the cocoapods team decides this is a valid feature request, I would like to help (if time permits :) )
I'd like to leave a comment there to just clarify that Development Pods do not preserve the folder structure.
I have s.source_files = 'NativeHelpWidget/Source/**/*.{swift,xib,storyboard}' in my podspec and it just flattens out whatever folder structure I might have with pod install on the demo app.
馃憤 @markltownsend I'm seeing the same
@kerrmarin and others.. I believe I got this working by including h,m in the list of extensions above.
So, s.source_files = 'NativeHelpWidget/Source/**/*.{h,m,swift,xib,storyboard}. After updating this and doing a pod install the folders showed up in the Development Pods.
Ah, thanks for that @markltownsend. What I found is that the folder structure is only preserved for folders that have a source file in them. For example:
pod install my project will show the group C but not A or B even though C is a child of B (and by extension A).pod install all groups appear.@dnkoutso is this expected behaviour?
Ah yes, that make sense too. I believe that the way that source_files works is that it takes the pattern and copies those files in the appropriate place in the development pod. I think Xcode then takes into account the folder structure. If there are no files, then no folder structure. But then I don't understand why the folder structure isn't kept when the pod is installed normally.
all files in one floder is very confuse,think more than 1000 file in one path, i want to folder structor too,
all files in one floder is very confuse,think more than 1000 file in one path, i want to folder structor too,
preserve_pod_file_structure is useful hhh
We recently needed this in one of our project and we were able to keep the folder structure by using the approach here. I think it just we need to create subspec and then setup correct source files and header files. This is working fine in our case.
+1 for this.
I've taken some unconventional measures to resolve issues with the project structure of my development pods (of which there are many for modualisation reasons). See here for more info... https://stackoverflow.com/questions/21168826/preserve-folder-structure-cocoa-pods/65511402#65511402
We can update preserve_pod_file_structure to take in a regex like share_schemes_for_development_pods and allow folks to specify the pods they want to preserve the structure for.
Most helpful comment
I'd like to leave a comment there to just clarify that Development Pods do not preserve the folder structure.
I have
s.source_files = 'NativeHelpWidget/Source/**/*.{swift,xib,storyboard}'in my podspec and it just flattens out whatever folder structure I might have withpod installon the demo app.