2010-05-23 13 views
1

Je suis en train de construire un framework, qui vise à fournir un nouvel environnement de développement pour l'utilisateur, mais j'ai besoin d'utiliser des choses comme RegexKit et presque certainement d'autres cadres établis pour ce faire. Toutes les fonctionnalités exposées à partir de ces frameworks seraient extraites par des classes et des méthodes dans mon propre framework pour des raisons de maintenance (ce qui me permet de changer d'idée sur les dépendances que je veux).Mon framework utilisera d'autres frameworks, mais je voudrais que cela soit transparent pour l'utilisateur final

Dans un monde idéal, je veux juste expédier un seul .framework. Cependant, je suis conscient que contrairement aux bundles et applications standard, il n'est pas possible d'intégrer un framework dans le bundle de framework. Est-ce que j'ai une autre option que d'indiquer à l'utilisateur final qu'il doit également installer RegexKit et toute autre dépendance? J'ai l'impression que cela réduit la valeur d'appel du framework embarqué facile à utiliser que j'avais envisagé de construire.

En ce moment, je me sens comme je l'ai quelques options limitées:

  1. Force de l'utilisateur pour installer les dépendances.
  2. Ecrivez mes propres classes qui offrent les mêmes fonctionnalités - heu!
  3. Si possible, essayez de lier statiquement les cadres tiers (est-ce possible ??)

Mon produit final est idéalement un seul faisceau de .framework qui utilise @rpath et peut donc être installé dans le système ou simplement regroupés avec l'application qui l'utilise.

+0

J'ai juste eu une pensée. Je pourrais vivre avec ça, si c'est possible. Puis-je créer un .bundle standard qui contient tous les frameworks de dépendances à l'intérieur de lui-même, puis fournir un mécanisme pour charger ce bundle à partir du framework principal? Ainsi, le développeur copie toujours un .framework et un .bundle dans leur projet. Effectivement toutes les dépendances sont alors contenues dans une sorte de plugin. Hmm, en pensant à cela plus je pourrais faire une API plus générale pour les plugins chargeables en utilisant le même API de chargement de paquets #thinkingoutloud – d11wtq

Répondre

0

Désolé de répondre à ma propre question, mais un ensemble chargeable est définitivement ce que je veux si je veux encapsuler les dépendances sans que l'utilisateur n'ait à se préoccuper de leur existence. En fait, j'envisage simplement de faire de mon framework un ensemble chargeable au lieu d'un framework car à première vue, il semble que vous puissiez obtenir plus ou moins la même chose, juste que la façon dont le code est chargé en mémoire diffère. Soit cela ou juste avoir deux fichiers: le framework et un bundle dont il a besoin pour fonctionner.

EDIT | Si quelqu'un a une meilleure réponse à la question initiale, je vais laisser cette question sans réponse pendant un moment.

+0

Apple le décourage fortement, mais vous pouvez créer un cadre parapluie. – JeremyP

+0

Ma compréhension des cadres parapluie est que les cadres qu'ils regroupent vivent ailleurs (tel est dans le système de fichiers, ou copié dans le groupe d'applications). C'est ce que j'essaie d'éviter. Myabe J'ai mal compris ce qu'est un cadre parapluie. J'ai l'impression que, par exemple, Cocoa est juste #import #import #import et rien en particulier dans le binaire. Le code vit tous dans les cadres respectifs. – d11wtq