ObjC: Jak skompilować bibliotekę statyczną, która zawiera opcjonalne klasy zależne od biblioteki innej firmy

Question

Próbuję znaleźć najlepszy sposób na spakowanie statycznej biblioteki (pozwala to nazwać ją Lib1), która zawiera opcjonalną klasę (na przykład ClassA), który sam wymaga drugiej biblioteki statycznej (Lib2). Innymi słowy, Lib2 jest potrzebny tylko wtedy, gdy odwołanie do klasy A w kodzie projektu. Wydaje się, że rzeczy działają dobrze, chyba że Lib1 jest używany w projekcie, który nie używa klasy A (a więc nie obejmuje biblioteki Lib2), ale wymaga flagi -ObjC linker (z powodu innych zależności projektu, nie mojej).

Próbuję wymyślić proste rozwiązanie dla trzech następujących scenariuszy:
1) Projekt obejmuje moje statyczne lib, nie korzysta z opcjonalnego klasę, nie precyzuje -ObjC flagę
2) projekt zawiera moją statyczną bibliotekę, NIE używa klasy opcjonalnej, ale wymaga flagi -ObjC
3) zawiera moją statyczną bibliotekę + drugą statyczną bibliotekę i używa opcjonalnej klasy (nie dbamy o flagę -ObjC na ten punkt)

Czy jest tam flaga linkera, aby usunąć moją opcjonalną klasę z końcowej aplikacji projektu, aby nie wymagała drugiej statycznej biblioteki? Sądzę, że moje inne alternatywy to wydawanie wielu wersji mojej statycznej biblioteki, która zawiera klasę opcji (standardowy wybór), taką, która nie działa (alternatywa dla projektów z wymaganiami -ObjC) lub może dostarczać plik pośredniczący, który dostarcza puste implementacje wszystkich klas wymaganych od drugiej biblioteki statycznej? Wygląda na to, że może to być typowy problem w świecie bibliotek statycznych ... czy istnieje najlepsza praktyka w tym scenariuszu?

Dzięki!

---

Rozwiązanie:

1) Zaproponuj do moich -ObjC użytkowników, którzy używają -force_load zamiast. (dzięki Rob!)
2) Dla użytkowników, którzy nie mogą wykonać 1, będę mieć alternatywną kompilację, która nie obejmuje klasy A

Answer 1

Najlepszą praktyką jest zawsze posiadanie końcowego łącza binarnego wymaganego przez wszystkie statyczne biblioteki . Nigdy nie należy pakować jednej biblioteki statycznej w drugą. Absolutnie nigdy nie należy pakować dobrze znanej (tj. Otwartej) biblioteki statycznej do statycznej biblioteki, którą wysyłasz. Może to wywołać niesamowite bóle głowy dla końcowego użytkownika, ponieważ mogą skończyć z wieloma wersjami tego samego kodu. Śledzenie błędów, które mogą z tego wyniknąć, jest szalenie trudne. Jeśli będą mieli szczęście, będą po prostu mylące błędy kompilatora. Jeśli mają pecha, ich kod będzie działał w nieprzewidywalny sposób i losowo się zawiesi.

Wysyłaj wszystkie statyczne biblioteki osobno. Powiedz swoim klientom, które z nich muszą połączyć w różnych konfiguracjach. Próby uniknięcia tego po prostu utrudniają życie.

niektórych innych dyskusjach, które mogą być użyteczne:

• Duplicate Symbol Error: SBJsonParser.o? (Przykład klienta, który prowadził do sprzedawcy w ten sposób do niego)
• Linking static libraries, that share another static library
• Why don't iOS framework dependencies need to be explicitly linked to a static library project or framework project when they do for an app project?

---

Flaga -ObjC powinna zapobiegać automatycznemu odpędzaniu z ClassA w całości, niezależnie od tego, czy jest używana, czy nie (więcej szczegółów można znaleźć w artykule TN1490).

Jeśli ClassA nigdy nie jest używany, z wyjątkiem pewnych okoliczności i chcesz zaoszczędzić miejsce, prawdopodobnie powinieneś przenieść ClassA do swojej własnej biblioteki statycznej. Lub użyj #ifdef, aby warunkowo go skompilować.

Alternatywnie można usunąć flagę -ObjC i użyć -force_load do samodzielnego załadowania jednostek kompilujących tylko kategorię (co jest problemem, do którego adres używany jest -ObjC).