Sto usando con successo moduli esplicitamente dichiarati come una soluzione di questo problema per il caso Objective-C -> Swift. Non ho separato la dichiarazione del modulo in una mappa di modulo privata separata ma ho dichiarato sia il modulo framework che un modulo esplicito all'interno della stessa modulemap a causa della preoccupazione sollevata in uno dei commenti alla domanda (non ero sicuro se o come è possibile utilizzare l'intestazione generata dalla mappa del modulo privato all'interno dello stesso framework).
Ecco un estratto del modulemap ho definito per il mio MPFoundation.framework, che include un modulo esplicito MPManuscriptCompiler_Protected
che importa l'intestazione "MPManuscriptCompiler+Protected.h"
che non è incluso nell'intestazione ombrello per il quadro:
framework module MPFoundation {
umbrella header "MPFoundation.h"
export *
module * { export * }
explicit module MPManuscriptCompiler_Protected {
header "MPManuscriptCompiler+Protected.h"
export *
}
}
ho quindi utilizzare questo modulo esplicita MPManuscriptCompiler_Protected nel mio sottoclasse Swift che è presente nello stesso quadro in questo modo:
import MPFoundation.MPManuscriptCompiler_Protected
La mia soluzione è in realtà tecnicamente solo una soluzione: per farlo funzionare, "MPManuscriptCompiler+Protected.h"
può essere contrassegnato come intestazione privata o di progetto nel framework, quindi non sarà visibile nell'intestazione dell'ombrello e non sarà disponibile per le importazioni basate sull'intestazione con il suo nome file. Quindi, questo funziona senza dover includere questa intestazione nell'intestazione dell'ombrello.
Tuttavia, il modulo creato in questo modo è esposto pubblicamente nel framework e disponibile per gli occhi che non dovrebbero vederlo. Non ho indagato ulteriormente perché in pratica questo risolve il problema abbastanza bene (sono ancora per colpire i problemi in cui avrei per caso importato quell'intestazione protetta dove non doveva essere importata).
Ciao, @ puru020, hai trovato una soluzione per questo? Ho esattamente lo stesso problema e non riesco a trovare come risolverlo. Grazie. – Daniel
Non ho. Non sembra esserci una soluzione. Quello che abbiamo deciso è di mantenere 2 sezioni nell'intestazione dell'ombrello per i file .h pubblici e privati. Una volta creato il framework, eseguiamo uno script che va ed elimina la sezione privata dell'intestazione dell'ombrello. – puru020
Ieri ho cercato ore per trovare soluzioni a questo problema. Il problema principale è la restrizione di non essere in grado di utilizzare un'intestazione di bridging nei framework. Per il caso "private objc-header in Swift", mi sono imbattuto nella definizione di un modulo privato, una funzione CLANG. Sfortunatamente, questo sembra essere lì per esporre intestazioni private ad altri framework, piuttosto che usare intestazioni private di objc in Swift. Anche se credo che ci sia una ragione per i problemi, in quanto l'interoperabilità sembra essere importante per Apple. Gradirei una risposta chiarificatrice. –