6

Tengo el Proyecto 1 con dependencias de Boost y GLM. Para Boost y GLM, he especificado los 'Directorios de inclusión adicionales' para hacer referencia a los archivos de C++ para cada uno. El Proyecto 1 se crea como un proyecto de biblioteca estática. Cuando construyo el Proyecto 1, todo se construye bien. Proyecto 2 Proyectos de referencia 1 a través del gestor de referencia, pero cuando construyo Proyecto 2, reciboCómo puedo heredar las dependencias/referencias del proyecto de un proyecto a un proyecto dependiente en Visual Studio

fatal error C1083: Cannot open include file: 'boost/something/etc.

para archivos en Proyecto 1. ¿Por qué recibiría errores sobre el Proyecto 1 cuando construyo el Proyecto 2? El Proyecto 1 también usa la biblioteca de expresiones regulares en Boost, que debe integrarse en un .lib antes de su uso. ¿Cómo puedo hacer que mi biblioteca estática de Project 1 incorpore la biblioteca ReGex de Boost y que GLM incluya archivos en ella? Para su información, el Proyecto 2 es un proyecto de prueba para el proyecto 1. Estoy queriendo algo como esto:

(lib expresiones regulares Boost + GLM incluye) -> Proyecto 1 ==> Project_1.lib

(unidad Boost test lib + Project_1.lib) -> Project 2 ==> Project_2.exe

--> indica dependencias/referencias y ==> indica salida.

¿Esto es posible? Obtuve más errores de compilación y errores de enlazador de los que puedo contar mientras gano las ruedas en esto.

+0

¿Tiene archivos fuente en el Proyecto 2 que incluyen archivos de encabezado del Proyecto 1? ¿Los archivos de encabezado del Proyecto 1 incluyen (directa o indirectamente) archivos de cabecera de Boost y/o GLM? –

+0

Sí, tengo un archivo en el Proyecto 2 y tiene uno incluye: #include "MyFileReader" Mi "MyFileReader" incluye tanto Boost como GLM. GLM es una biblioteca de solo encabezado, fyi. – Wagan8r

+0

Luego, haré lo que Preet sugiera y emplee declaraciones avanzadas y/o el modismo PIMPL para evitar exponer los detalles de implementación del Proyecto 1 a sus consumidores. –

Respuesta

5

Esto es probablemente porque parte del código (encabezado y/o implementación) en su Proyecto 2 incluye encabezados del Proyecto 1, que a su vez incluye encabezados de biblioteca externa que no están en la ruta de inclusión para el Proyecto 2. El efecto neto es que después de expandir todos los #include, su archivo fuente del Proyecto 2 tendrá una línea que dice algo así como: #include <boost/something/etc> que no podrá expandirse ya que no está en la ruta de búsqueda del proyecto 2.

Este error se producirá independientemente de que haya compilado estáticamente esas bibliotecas externas en su project1.lib.

Si no es un problema, simplemente agregue la biblioteca externa que incluya rutas a los directorios VC++ del Proyecto 2> incluir directorios.

Una forma de evitar esto es mover tantas bibliotecas externas como fuera de los encabezados del Proyecto 1 y ocultarlas usando una combinación del patrón PIMPL y las declaraciones de reenvío. Pero para cosas como las bibliotecas de encabezado único o pesadas de plantillas, creo que deberá incluir esas rutas de encabezado y no hay forma de evitarlas a menos que encapsule la funcionalidad u oculte la implementación detrás de una clase/interfaz del Proyecto 1.

+0

Gracias. Seguí adelante y acabo de hacer que mi proyecto dependiente incluya el código al que se hace referencia. Tanto las declaraciones PIMPL como las posteriores parecen ideas claras, pero realmente no quiero volver a escribir un montón de código solo para fines de compilación. Sin embargo, es una gran cosa para agregar a mi conocimiento. – Wagan8r

1

También la respuesta de @PreetKukreti es correcta, después de corregir los encabezados todavía hay una dependencia más a las bibliotecas externas (impulso & GLM) porque las bibliotecas estáticas predeterminadas no se vincularán con las dependencias externas. Esto se debe a un simple caso de error que explicaré aquí:
Utiliza una función por ejemplo strlen de CRT y desea fusionarla con su salida .lib, luego strlen se fusionará en su .lib y luego en su proyecto de prueba (.exe) usa strlen nuevamente, y usted ya sabe que en bibliotecas estáticas todo es público, por lo que cuando se vincula con CRT y su .lib tiene que implementar strlen y esto generará un error de enlazador.
De manera predeterminada, VisualStudio no enlazará las dependencias de la biblioteca.lib a menos que le diga que haga eso (Propiedades de la solución-> Bibliotecario-> Dependencias de la Biblioteca de enlaces) y no debe configurarlo en sí a menos que realmente sepa qué está haciendo allí y acepte las consecuencias de su acción.
Por lo tanto, en cualquier caso, es mejor colocar la ruta de las bibliotecas externas (impulsar & GLM) en la ruta del proyecto 2 o compilar el proyecto 1 como una DLL que solo expone ciertos objetos indicados y también intentar usar la respuesta de @PreetKukreti y mueva los archivos de inclusión innecesarios a los archivos de implementación (.cpp).

Cuestiones relacionadas