Incluir bibliotecas en el proyecto de la biblioteca de iOS

Estoy escribiendo una biblioteca de iOS que depende de algunas otras bibliotecas de código abierto. Al parecer, no es posible tener dos classs con el mismo nombre, por lo que es posible que la biblioteca compile, y un proyecto que potencialmente podría usarlo también comstack, pero no funcionan bien juntas (en la fase de enlace).

La biblioteca está dirigida a una gran audiencia, por lo que no puedo hacer suposiciones sobre si estos desarrolladores importarán las mismas bibliotecas o no, o si podrían estar utilizando una versión diferente e incompatible de las mismas bibliotecas.

He estado buscando pero no pude encontrar una solución clara a mi problema (quizás no lo haya). Hasta ahora estoy pensando en estas opciones:

  • Informe a los usuarios que las bibliotecas X ya están incluidas en el proyecto, por lo que no las incluyen también. Esto significa que no pueden usar una versión diferente de las bibliotecas X.
  • Como una versión refinada de la primera, use CocoaPods, por lo que las dependencies se resuelven automáticamente. Todavía tiene la desventaja de que dos versiones de la biblioteca no pueden coexistir.
  • Importe y cambie el nombre de todas las classs de las que depende mi biblioteca, prefijos, para que los nombres no entren en conflicto con los originales. Este es un trabajo tedioso, pero lo que es más importante, tiene la desventaja de que no podría extraer / empujar código de / a la biblioteca original, ya que el código cambiaría demasiado. Todavía me parece la mejor opción desde la perspectiva del usuario.

¿Puedes pensar en una mejor idea? Soy muy nuevo en los proyectos de la biblioteca, así que tal vez hay algo obvio que me falta.

Todavía no estamos decididos a distribuir en forma de código binary o fuente. Si hay una razón para elegir uno u otro, también me gustaría escuchar su opinión.

Cuando tuve este problema, elegí tu tercera opción y prefijé las classs dependientes dentro de mi biblioteca. La razón por la que podría considerar hacer esto en lugar de depender del usuario para importar los demás sería que puede garantizar la compatibilidad y no tiene que preocuparse por las versiones de la persona de la que depende.

Primer punto –

Informar a los usuarios que las bibliotecas X ya están incluidas en el proyecto, por lo que no las incluyen también

por lo que tiene una biblioteca estática Foolib.a , tiene una dependencia de terceros Barlib.a , para que Foolib compile, los HEADER_SEARCH_PATHS de HEADER_SEARCH_PATHS deben establecerse en la ruta de acceso de los encabezados públicos de Barlib. No más.

Si está distribuyendo su código fuente, puede usar CocoaPods (este es un buen path a seguir), o puede agregar el repository de Barlib como un submodule git (o lo que sea para su elección de VCS) de su repository y el código duro HEADER_SEARCH_PATHS a ese ruta, o puede requerir que su usuario tome su propio Barlib y edite manualmente HEADER_SEARCH_PATHS a la ruta correcta (si va a la ruta CocoaPods o submodule, el usuario puede hacerlo fácilmente, así que tiene más opciones).

Nada de Barlib está 'en' su proyecto.

Por otro lado, si está distribuyendo un binary para que su usuario pueda vincularlo a su aplicación, debe especificar en sus instrucciones que Foolib requiera que Barlib esté vinculado a la aplicación. Las instrucciones para get Barlib sería agradable.

Nada de Barlib está 'en' su proyecto o comstackdo en su biblioteca.

Segundo punto:

use CocoaPods, por lo que las dependencies se resuelven automáticamente. Todavía tiene la desventaja de que dos versiones de la biblioteca no pueden coexistir

No es posible realizar dos versiones de la misma biblioteca en una aplicación, pero la situación en la que el usuario final ya requiere Barlib 3.0, quiere usar tu Foolib, pero Foolib requiere que Barlib 4.0 no tenga que popup nunca. Depende de usted, el desarrollador . Puede ser generoso y admitir varias versiones de Barlib (es decir, todo lo que Foolib necesita para trabajar es un Barlib1.0, Barlib2.0, Barlib3.0 O Barlib4.0 vinculado a la aplicación, similar a escribir una aplicación que admita iOS5 e iOS6) o, puede ser de opinión y requerir una versión específica, y si el usuario ya está requiriendo una versión diferente de Barlib, mala suerte, tendrán que cambiar su código si quieren usar su biblioteca.

Tercer punto

Importar y cambiar el nombre de todas las classs de las que depende mi biblioteca, prefijándolos, para que los nombres no entren en conflicto con el original

Esto es demasiado terrible para que lo considere en este momento. Lo siento.

Nada de Barlib está 'en' su proyecto o comstackdo en su biblioteca. No distribuye ninguna copy de Barlib, ya sea vinculada a su código binary o como fuente.