[Add] LibComponentLogging-pods 0.0.2

[aharren]

adapt lcl_configure to new location of build headers in CocoaPods 0.34.x and 0.35.x

[aharren]

@orta @Keithbsmiley @alloy sending this via pod trunk push didn't work, because the Xcode project from the linting process doesn't compile (due to missing lcl_config* files), and there's no --quick for pod trunk push; therefore, I'm sending this as a pull request.

[aharren]

@orta @Keithbsmiley @alloy any thoughts on this?

[orta]

FWIW doing it this way won't get added to web properties ( e.g. search, cocoadocs etc ) but would still work fine generally. Do you know if there's anything we can do to make it lint correctly? ( /cc @kylef )

[aharren]

A trunk lint --quick option would be cool, just like pod spec lint has.

Building an Xcode project requires some config files which don't exist in a plain project. So, I assume that all related specs couldn't be updated via trunk at the moment.

[aharren]

What also could help would be a possibility to add something locally to the Podfile which is created and used by pod trunk push. Then I could add the auto-configuration pod and a post-install hook which could create the config files.

[aharren]

@orta @kylef adding the following lines to the Podfile which is used by pod spec lint or pod trunk push could help and would create the required config files:

post_install do |installer|
  system 'Pods/LibComponentLogging-pods/configure/lcl_configure pod'
end

BTW is linting always using the folder /tmp/CocoaPods/Lint? What happens if pod spec lint is run in parallel on the same machine? (~> shouldn't the temp folder be a unique temp folder (like with mkdtemp)?)

[kylef]

@aharren You could make a CocoaPods plugin which add's this hook, as of version 0.36 you will need to explicitly define which plugins you want in your Podfile which means you'd have the same problem.

I'm wondering if we can add a --plugins option to pod {spec,lib} lint to allow using plugins which change how the linting works.

That, or we could allow you to create the Podfile manually and pass it to the linter. @kapin, what do you think?

---

You are right, currently it will fail if you try linting two things at once. I'd normally use pod spec lint <podspec1> <podspec2> ... to lint multiple specs at once. Please create an issue in CocoaPods to support this, or better yet. Perhaps a pull request changing this behaviour. I think the change would be mostly isolated to the single line over at https://github.com/CocoaPods/CocoaPods/blob/master/lib/cocoapods/validator.rb#L178-182.

[joshkalpin]

@kylef I feel like that would be a massive change for the linter. I'm kind of concerned about the long-term effects of that too. I'm just getting into exam season, so I can't really look into it until the middle of December.

[kylef]

@kapin, fair enough.

In that case, let's merge this manually. @aharren, you will need to continue using pull-requests until we find a long-term solution for this problem.

[aharren]

Thx.

You are right, currently it will fail if you try linting two things at once. I'd normally use pod spec lint ... to lint multiple specs at once. Please create an issue in CocoaPods to support this, or better yet. Perhaps a pull request changing this behaviour. I think the change would be mostly isolated to the single line over at https://github.com/CocoaPods/CocoaPods/blob/master/lib/cocoapods/validator.rb#L178-182.

@kylef I was thinking about a continuous integration environment where multiple pod calls may run in parallel (for different jobs). I'll have a look at the mentioned lines.