xcode - @import causa un problema de análisis: "no se pudo construir el módulo"

xcode6.3

Question

Después de actualizar con Xcode 6.3, encontré algo extraño en mis proyectos.

Debajo de los códigos se produce el problema de análisis que dice "No se pudo compilar el módulo ''AgendaFramework''", el marco de trabajo de AgendaFramework es personalizado para ios8:

@import MyEmbededFramework;

El marcador de error se ve así:

Los problemas se plantean durante la indexación no se construye. Todo el edificio se puede realizar con éxito sin ningún error o advertencia. Puedo compilar, archivar, ejecutar en dispositivo, implementar, enviar a App Store.

Sin embargo, el marcador de error aparece cuando edito las clases que pertenecen a la extensión. La extensión (widget) explícitamente vinculada al marco incrustado. (Sé que no tengo que hacerlo cuando utilizo la declaración @import).

En este estado, no pude recibir ningún asistente de contenido válido, muy molesto.

Después de reemplazar la declaración de importación con el estilo anterior, el problema desapareció:

#import <AgendaFramework/AgendaFramework.h>

Tengo varios otros proyectos que tienen una topología muy similar con el proyecto que causa este problema, pero están bien. Solo un proyecto causa este problema. Comparé cada detalle de configuración de compilación, no pude encontrar ninguna pista.

Lo intenté:

• Eliminar datos derivados
• Full Clean
• Reiniciar

Cualquier pista es bienvenida. ¡Gracias!

Answer 1

A veces, este problema se puede resolver agregando el marco a la misma carpeta que el archivo .xcodeproj , sin subcarpetas ni nada.

Créditos a Jonny quien lo señala como un comentario en la pregunta.

Answer 2

Desactiva el módulo en la configuración de compilación. Eso puede funcionar

Answer 3

Hoy resolví este problema con esos pasos ,:

1. Eligió el esquema "MyEmbededFramework"
2. Presiona [Command + B] para construir
3. Desde el panel de fase de compilación, agrega "MyEmbededFramework.framework" para vincular el binario con las bibliotecas

Intenta construir tu proyecto, el problema puede desaparecer ahora.

Answer 4

Parece que está activando: Permitir inclusiones no modulares en Framework Modules resolvió este problema para mí.

Answer 5

Solución que funcionó para mí: diligencia en la orientación del archivo de cabecera del framework a las importaciones de estilo de sistema ... como #import <CoreXLib/CoreThreads.h> la historia:

En mi caso, mi framework que construí vino de la combinación de varias bases de código, ya que se hizo evidente que podía reutilizar algunos de los patrones de diseño generales a través de ese código easer vía Framework versus los frágiles nombres de ruta del proyecto Xcode.

A medida que construía mi marco "CoreXLib", lo reorganicé en el Marco Cocoa típico de Xcode. Cambié mis importaciones de:

    #import "CoreTypeAliases.h"    // project local style   

a

    #import <CoreXLib/CoreTypeAliases.h>    // system or framework style

adecuadamente. Varios proyectos que usaban CoreXLib.framework que incluye los encabezados públicos en la carpeta de lego funcionó ... así que pensé que era bueno para ir ...

Lamentablemente, algunos de los encabezados que eran públicos no se actualizaron por completo. Las clases en el marco construido muy bien en el estilo local. Todos los proyectos que lo usaron funcionaron hasta este punto y luego me encontré con uno que no ... y el error anotado por @jeeeyul

Entonces, después de encontrar este hilo y encontrar la solución de @kwz, y no tener nada que hacer en mi caso, decidí pulir el código mientras intentaba resolver este problema. En el proceso de pulido, descubrí que algunas de las #imports no se cambiaron como deberían en la búsqueda de Xcode y reemplazan. Es hora de tocar la mano ...

Después de arreglar todas esas referencias en todos mis encabezados de proyectos CoreXLib (no solo los públicos, defensa personal), volví al problema ... Llevé el CoreXLib.framework recién terminado al proyecto errante que lo incrustó . .. y el problema se había desvanecido! Revisé el Allow Non-modular Includes... tanto en el proyecto marco como en el proyecto que vinculó el marco y ambos fueron "No". Al pasar ambos a "Sí" y a "No" no hubo diferencia en varias pruebas. El único otro cambio fueron las modificaciones #import "..." a #import <CoreXLib/...> .

Entonces, a veces, pulir la manzana 🍎 golpea a los insectos🐞🐞off ...

Answer 6

puedes probar esto, es trabajo para mí. eliminar DerivedData dir que sobre su proyecto. paso a paso