Cómo evitar redefinir VERSIÓN, PAQUETE, etc.

Question

No he visto ninguna pregunta relacionada con las compilaciones de GNU autoconf/automake, pero espero que al menos algunos de ustedes estén familiarizados con ellas.Aquí va:

Tengo un proyecto (lo llamaré miproyecto) que incluye otro proyecto (proveedor).El proyecto del proveedor es un proyecto independiente mantenido por otra persona.Incluir un proyecto como este es bastante directo, pero en este caso hay un pequeño inconveniente:cada proyecto genera el suyo config.h archivo, cada uno de los cuales define macros estándar como PAQUETE, VERSIÓN, etc.Esto significa que, durante la compilación, cuando se crea el proveedor, recibo muchos errores como este:

... warning: "VERSION" redefined
... warning: this is the location of the previous definition
... warning: "PACKAGE" redefined
... warning: this is the location of the previous definition

Éstas son sólo advertencias, al menos por el momento, pero me gustaría deshacerme de ellas.La única información relevante que he podido encontrar con una búsqueda en Google es este hilo en la lista de correo de automake, que no es de mucha ayuda.¿Alguien más tiene alguna idea mejor?

Answer 1

Algunas notas:

• no mencionaste cómo config.h se incluyó, entre comillas o corchetes angulares.Ver esta otra pregunta para obtener más información sobre la diferencia.En breve, config.h normalmente se incluye entre comillas, no entre corchetes angulares, y esto debería hacer que el preprocesador prefiera el config.h desde el propio directorio del proyecto (que normalmente es lo que desea)
• Usted dice que un subproyecto debería incluir el proyecto adjunto. config.h Normalmente esto no es en absoluto lo que quieres.El subproyecto es independiente y su PAQUETE y VERSIÓN deben ser los de ese subproyecto, no el suyo.Si incluye libxml en su proyecto xmlreader, por ejemplo, aún querrá que el código libxml se compile con PACKAGE libxml y VERSION (cualquiera que sea la versión de libxml).
• Suele ser un gran error tener config.h incluirse desde encabezados públicos. config.h siempre es privado para su proyecto o subproyecto y solo debe incluirse desde archivos .c.Entonces, si la documentación de su proveedor dice que incluya su "proveedor.h" y ese encabezado público incluye config.h de alguna manera, entonces eso es un no-no.De manera similar, si su proyecto es una biblioteca, no incluya config.h en cualquier lugar desde sus encabezados instalados públicamente.

Answer 2

Definitivamente es un truco, pero posproceso el autogenerado. config.h archivo:

sed -e 's/.*PACKAGE_.*//' < config.h > config.h.sed && mv config.h.sed config.h

Esto es tolerable en nuestro entorno de construcción, pero me interesaría una forma más limpia.

Answer 3

Resulta que en mi caso había una solución muy sencilla.El proyecto del proveedor reúne varios archivos de encabezado en un archivo de encabezado monolítico, que luego se #included por las fuentes del proveedor.Pero la regla de creación que crea el encabezado monolítico incluyó accidentalmente el config.h.La presencia del PAQUETE, VERSIÓN, etc.Las variables de configuración en el encabezado monolítico son las que causaban las advertencias de redefinición.Resulta que el vendedor config.h era irrelevante, porque "config.h" siempre resolvió $(top_builddir)/config.h.

Creo que así es como se supone que debe funcionar.De forma predeterminada, un subproyecto debe incluir el proyecto adjunto. config.h en lugar del suyo propio, a menos que el subproyecto incluya explícitamente el suyo propio o manipule la ruta INCLUDE para que su propio directorio esté antes $(top_builddir), o manipula de otra manera los archivos de encabezado como en mi caso.