[Specification] Allow specifying a custom module map file

[segiddins]

\c @kylef @mrackwitz

• Lint to prevent module_map defined on a subspec. depends on [Specification::DSL] Fixes around Linter and Analyzer #233.
• Changelog

[orta]

So this is a breaking change that would require a Specs repo update if someone pushes a pod from a beta/master to the repo, are there any other DSL attributes we should add if we're doing this?

[segiddins]

Didn't we already add the module_name attribute?

-Samuel E. Giddins

On Feb 14, 2015, at 9:42 AM, Orta [email protected] wrote:

So this is a breaking change that would require a Specs repo update if someone pushes a pod from a beta/master to the repo, are there any other DSL attributes we should add if we're doing this?

—
Reply to this email directly or view it on GitHub.

[orta]

Legit point, and it's being used, ignore me.

[segiddins]

I think this was one of the huge benefits of switching to JSON

[mrackwitz]

So with subspecs, I see the following two cases:

• Without custom modulemap: The generated modulemap will inject the generated umbrella header, which takes care of importing all public headers, including those of subspecs. Importing the full Clang module, will give you everything. But you can also import implicitly derived submodules by using e.g. MyPod.MySubspecHeader.
• With custom modulemap: The custom modulemap will be used and injected by the build setting in the generated target. Because this is given, there is also no need to generate an umbrella header. All public headers, even those of the subspecs, need to be transitively imported or known to the modulemap by explicitly enumerating them. In consequence, the pod authors would need to make sure, that they provide a public header with precompiler-guards with conditions for header-availability for each subspec (and eventually have something like a sub-umbrella-header for each subspec), so that the resulting Clang module does include the fulll public interface, including the subspecs.

[segiddins]

@mrackwitz sure. I think specifying your own module map is like 'hard mode' -- you're responsible for it doing the things it should. I don't think we'll recommend that anyone use it -- it'll just be an option for those who need it. As to dealing with subspecs -- sure, that'd be nice, but (a) that would all be inside CocoaPods/CocoaPods and (b) it's 1/2 unrelated to this -- it can be done separately.

[mrackwitz]

but (a) that would all be inside CocoaPods/CocoaPods and (b) it's 1/2 unrelated to this -- it can be done separately.

We could i.e. go a whole different approach and allow customizing the generated modulemap in the DSL, so that you could add modulemap-declarations also on the subspec level.
It's a bit of intentional overthinking as it isn't based yet on actual issues. Intentional because changing the DSL back and forth is limited, so we should take care and allow an extensible design, which is compatible with existing features.
After all, this seems to be given, so from my side, we're definitively good to go for this approach. 👍

[segiddins]

two spaces

[segiddins]

Other than the one CHANGELOG comment and the linting, this should be good to go once the work in CocoaPods is done and #233 has been finished.

[orta]

This'll need a rebase 👍

[mrackwitz]

Done! With the change of 1375f0f, which affects how the linter is tested, I discovered a duplicated warning, introduced with #233, which I fixed right here on this branch.

[segiddins]

why is this removed?

[mrackwitz]

238a282: The author attribute is specified in the DSL as :required => true, so it's linted automatically and we can rely on that. :)

[mrackwitz]

This should be then ready now. Anything else left?

[segiddins]

Nope, this is good! 👍