[WIP] MailCore 0.2.7

[jwilling]

This is just a template to get us started. Can you let us know how this project is structured, @mronge? What about build scripts?

[fabiopelosin]

The scripts appear to be related only to documentation generation, so with I think that you can just add:

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

The dependencies appear to be:

• https://github.com/mronge/libetpan
• https://github.com/mronge/iOSPorts

It is unclear to me if those forks diverge from their original counterparts in a significative way. Anyway a good start is to create a podspec for them and point the sources files to src/**/, maybe you also need to add the include folder. From this using pod spec lint it is pretty easy to check if you are missing any file (or compiler flag).

[jwilling]

I'll give it a shot.

[jwilling]

@irrationalfab If spec lint claims that a pod build successfully, can I trust it? 😜

[mronge]

It would be awesome if you could add iOS as a deployment target for MailCore as well.

The MailCore project itself needs no external build scripts, but it does depend on libetpan. Libetpan in turn depends on Cyrus-SASL which is in iOSPorts (older version of libetpan also require OpenSSL for iOS, the latest version does not)

If we can get Cyrus-SASL building and then LibetPan building with cocoapods then MailCore should be good to go.

The reason I forked both projects was to add things like armv7s support with the original repository authors had not added.

[alloy]

@mronge Do you think these are changes the original authors would or would not accept?

At least for iOSPorts there has been a start by someone: bindle/iOSPorts#4.

[fabiopelosin]

@irrationalfab If spec lint claims that a pod build successfully, can I trust it?

Short answer

I do 😄

Long answer

The linter builds a podfile in memory that requires the pod, then it proceeds to install it (without integration) in a temporary directory, and finally after performing some checks builds the resulting Pods project using xcodebuild. Unless you missed all the source files (and in that case the linter should warn you) in the 99% of the cases project shouldn't build unless you are including all the files and the necessary compiler flags.

Naturally it means that all the dependencies of the pod (which implicitly are installed by the linter) should build as well.

If you want to see all the process as usual you can use the --verbose option.

[rwyland]

@alloy I started down the path with adding the podspec for the iOSPorts project and was dividing up the inner-dependencies when I hit a roadblock with the make files. My latest spec is in the referenced ticket.

@jwilling @mronge If you want to get CyrusSASL started, you will first need to do the OpenSSL module since it is an inner dependency. If you would like, use the podspec I started and just add in the pre install hook. I need to finish my work with getting all 5 modules added into cocoapods, but since I'm in the midst of a different project at the moment, I would appreciate if you gave it a shot and I will add the remaining modules down the road. Thanks!

[jwilling]

@rwyland I'll attempt to create one for CyrusSASL, but I'm rather lost when it comes to more complex pods. I'll give it a shot though.

[fabiopelosin]

@jwilling I'm giving a look to iOSPorts (as a sing of gratitude for your contributions to ikeda).

[jwilling]

😂

[fabiopelosin]

iOSPorts is certainly not a trivial podspec. Some changes need to be made to CocoaPods (the FileList is not refreshed after the pre-install hook and allow pre-install hooks for subspecs) to support this podspec in a reasonable way (there are a lot of patterns to exclude for OpenSSL).

[jwilling]

Oh my. Thank you so much for your help on this! 😄

[mronge]

@irrationalfab Any suggestions on how I might be able to help out with the iOSPorts podspec? I'd really like to get MailCore working with Cocoapods, and that of course requires that both iOSPorts and LibEtPan are first added to Cocoapods.

[fabiopelosin]

This issue got stalled because CocoPods went through a partial rewrite which is almost complete. However the podspec that I was working on is a stretch, because it would use CocoaPods as a partial build system, good for making CocoaPods flexible but not good in the long run. Luckily a more robust and performant solution would be pretty simple, to have a repo where the result of the make file is committed so there is no need for CocoaPods to run it. Bonus points if the files not used on iOS are deleted so the podspec remains clean. This last step involves some work because it requires to check which build files are included in the target of iOS Ports and remove the rest.

@mronge If you need any support with it, just let me know :-)

[orta]

Anyone know the status of this? I know from talking to @irrationalfab about another podspec that the subspec post-pre hooks still aren't around but are a target for the next release. Do we need to keep this PR open?

[jwilling]

I'll close it for now, but this will have to be re-opened some time in the future.