Свифт: экспорт API зависимости

Предположим, у нас есть 2 каркаса, написанных в Swift: A.framework и B.framework, A зависит от B. Я хочу, чтобы каждый проект зависел от A, чтобы иметь возможность доступа к api рамки B без необходимости import B в исходных файлах проекта. Как это можно достичь?Свифт: экспорт API зависимости

EDIT: В частности, меня интересует, как это можно сделать с помощью Cocoapods.

ДРУГОЕ ИЗОБРАЖЕНИЕ: Я думаю, что будет полезно, если я объясню контекст, в котором возникает этот вопрос, потому что я до сих пор не получил подходящего ответа, несмотря на его продолжительность и щедрость.

Итак, у меня есть pod Freestyler (https://github.com/cayugasoft/Freestyler), который сам по себе зависит от pod FreestylerCore (https://github.com/cayugasoft/FreestylerCore). Хорошо работает, но я должен import FreestylerCore в проекте, даже если import Freestyler сделан. Это выглядит немного раздражающе для меня, потому что я рассматриваю эту зависимость (Freestyler -> FreestylerCore) как деталь реализации, и я хотел бы, чтобы пользователи библиотеки автоматически работали, не импортируя ничего, кроме основного контейнера, Freestyler. Поэтому я задал этот вопрос. Есть ли способы реализовать это?

источник

2016-11-14 Alexander Doloz

исправить меня, если не так, поскольку A зависит от B и имеет импорт B в исходных файлах A. Теперь вы хотели бы иметь проект P без необходимости импорта B в исходные файлы P? Это правильно ? Если это так, вы в конечном итоге хотите добавить B как зависимость для A и добавить только A как зависимость P? –

@PenkeySuresh: В основном я хочу что-то вроде заголовка зонтика в Objective-C. Вы импортируете этот заголовок, и все другие заголовки импортируются автоматически, и вам не нужно импортировать их вручную. Мне интересно, есть ли механизм для реализации подобного поведения, но в Swift. –

Я думаю, что вы ищете '@ _exported'. – HAS

Оказывается, что в Swift это поведение по умолчанию.

Если Pod.A зависит от Pod.B, то ваш проект, который зависит от Pod.A (через включение Pod.A в ваш подфайл), действительно будет иметь видимость для Pod.B.

Чтобы посмотреть пример настройки Pod.A, который имеет зависимость, а затем проект примера, который потребляет Pod.A (а также имеет видимость для Pod.B), см. Мою демонстрацию Public GitHub Repo для этого:

https://github.com/ericwastaken/CocoaPod-Dependency-Demo

Я добавил комментарии к примеру App (ViewController), который показывает эту работу. У репо есть дополнительные объяснения.

источник

2016-11-24 06:08:40 ericWasTaken

Благодарим вас за ответ, @ericWasTaken. К сожалению, это не то, что я имел в виду. Понятно, что вы можете использовать pod B в проекте, который зависит от pod A, * если вы импортируете pod B *, но я спросил, как достичь этого * без импорта pod B, только импортируя pod A *. Я посмотрел на ваш пример github - если строка 'import StackO_Dependency_Demo' в ViewController закомментирована, код не будет компилироваться. –

Мое приложение никогда не ссылается на Pod.B в подфайле. Pod.B - это React pod! Мой пример ссылается только на Pod.A, и это автоматически дает вам доступ к Pod.B (реактивный блок), который поступает через Pod.A (StackO pod = Pod.A). Конечно, если вы удалите Pod.A, он не будет построен. Это основной Pod, используемый в контроллере представления.В любом случае, возможно, вы ищете статическое включение логики Pod.B. Вы можете, конечно, довести эти классы до своего PodA и скомпилировать их как единый Pod. Но это не так, как CocoaPod в конечном итоге работает и не для чего. – ericWasTaken

Да, глядя на ваш вопрос сейчас, если вы вообще не хотите выполнять операции импорта, тогда вам нужно включить логический код/классы Pod.B в ваш Pod.A. Возможно, вы можете превратить Pod.B, а затем добавить к нему свою собственную логику. По крайней мере, таким образом, вы сможете объединить изменения в свою вилку в будущем. – ericWasTaken

Свифт: экспорт API зависимости

ответ

Смежные вопросы