tools - Eclipse CDT no está construyendo proyecto en el cambio de archivo de encabezado

plugin eclipse c c++ development tools (3)

Tengo Eclipse Platform 3.7.2 y CDT 8.0.2.

Cuando quiero hacer encabezados ''Build All'' desde otros proyectos de espacio de trabajo no se cuentan como dependencias y no se reconstruye nada.

Tengo una aplicación Hello World y un proyecto de biblioteca estática. La biblioteca estática se establece como una referencia en Propiedades del proyecto -> c / c ++ general -> Rutas y símbolos -> pestaña Referencias -> marcado ''Activo''. Esa es la única configuración que cambié.

Por cierto, me sorprende por qué Eclipse tiene un elemento adicional de nivel superior "Referencias del proyecto" en Propiedades del proyecto.

De todos modos, probé tanto el generador externo (que se selecciona por defecto en la creación del proyecto) como el generador interno, también acoplado con combinaciones de la configuración global ''Preferencias -> c ++ -> Construir -> Construir configuraciones solo cuando hay cambios de recursos de Eclipse ........ ''

Gracias por cualquier idea sobre esto.

Actualización: Esta es la salida de la consola al generar el proyecto dependiente Proj2 (Proj1 es la lib). se llama a ''hacer todo'' pero simplemente se vuelve a vincular, no recompila Main.cpp como debería. ¿Alguien que esté familiarizado con los archivos make generados por eclipse? Gracias de nuevo.

**** Build of configuration Debug for project Proj2 **** make all Building target: Proj2 Invoking: Cross G++ Linker g++ -L"/home/user/.eclipse-workspace/Proj1/Debug" -o "Proj2" ./Main.o -lProj1 Finished building target: Proj2 **** Build Finished ****

Editar: Ya tiene 1,5 años, quería agregar que se había registrado un error de Eclipse para esto: https://bugs.eclipse.org/bugs/show_bug.cgi?id=375800

Simplemente lanzando esto, ¿pero no necesitarías incluir los encabezados de la biblioteca estática en tu código de cliente? En ese caso, creo que necesitaría agregar los encabezados en la pestaña de inclusión de las propiedades del proyecto para su cliente. De lo contrario, no estoy seguro de cómo accedería realmente a la implementación de lib estática en su cliente.

En cuanto a las dos pestañas de references , creo que la que se encuentra en C / C ++ general se puede definir por separado para diferentes configuraciones, mientras que la más general es para cualquier configuración.

Actualizar:
Sugiero usar esa pestaña de reference más general que ha comentado. Esto debería asegurar que su cliente se refiera a otros proyectos sin importar cuál sea la configuración seleccionada actualmente del cliente o proyecto referido.

Otra actualización:
Me acabo de dar cuenta de que mencionaste que la única configuración que cambiaste fue la de references . Es otra posibilidad remota, pero también verificaría si las rutas de inclusión para la lib estática aparecen realmente en la pestaña de inclusión de la configuración de los proyectos (probablemente lo sea). Entiendo que la ruta de inclusión correcta se está utilizando en tiempo de compilación, pero eclipse (posiblemente) usa esta pestaña para determinar las dependencias incluidas al decidir iniciar una recompilación del proyecto del cliente. También podría valer la pena revisar la pestaña "Ubicación de origen" e intentar agregar la ubicación del encabezado como ubicación de origen.

Lo más seguro es "Limpiar" primero el proyecto principal y luego reconstruirlo. A menudo, cuando sé qué archivos del proyecto principal utilizo los archivos de encabezado modificados, simplemente "toco" esos archivos y luego los reconstruyo. "Tocar" para mí es solo agregar un espacio en una línea, generalmente una de las líneas #include en la parte superior del archivo. A continuación, ese archivo se reconstruye y recoge el encabezado modificado. Otros archivos que pueden usar ese encabezado no se reconstruirán, por lo que esto es peligroso. Por ejemplo, si cambió la firma de una llamada a método y la reconstruye de esta manera, solo el archivo invocará correctamente el nuevo método. La llamada desde otros archivos fuente probablemente hará que su programa se quede atrapado. La ventaja, por supuesto, es la velocidad de reconstrucción. Especialmente cuando hago pruebas unitarias, sé exactamente qué pruebas voy a ejecutar, así que solo toco los archivos relevantes, reconstruyo la ejecución. En algún momento por seguridad siempre hago un ciclo de limpieza / construcción. generalmente espero hasta que necesite más café.

existe un error para este problema: https://bugs.eclipse.org/bugs/show_bug.cgi?id=375800

Y una solución práctica y ordenada (el solicitante original ya lo sabe). Así que simplemente me entrelace a la respuesta real :) https://bugs.eclipse.org/bugs/show_bug.cgi?id=375800#c11

Todos los créditos a Krzysztof Czaińsk

En la configuración del compilador de su proyecto c o c ++, agregue -MT ${OUTPUT_PREFIX}${OUTPUT} después de las banderas:

${COMMAND} ${FLAGS} -MT ${OUTPUT_PREFIX}${OUTPUT} ${OUTPUT_FLAG} ${OUTPUT_PREFIX}${OUTPUT} ${INPUTS}

Esto creará los archivos .d correctos

Además: la solución tiene un efecto secundario. Después de una limpieza, make all se ejecuta siempre dos veces antes de que no diga nada que hacer. Aún mejor que no compilar después de un cambio ;-)