2009-11-27 21 views
6

Escribo mi propia biblioteca de pruebas unitarias (usando autoconf, automake y libtool) para que se ajuste mejor a mis necesidades (no necesito una gran cantidad de características, solo un corredor de prueba y aserciones). He llegado al punto en que parece ser utilizable.Autoconf - ¿A dónde va config.h?

Por supuesto, usa una config.h para descubrir qué encabezados incluir. El problema es que no estoy seguro de dónde debe ir config.h, ya que tenderá a chocar fácilmente con la configuración de otro proyecto, así como con el hecho de que depende de la arquitectura.

¿Cuál debería ser mi método para instalar este encabezado? (Es necesario para todos los demás encabezados)

+6

El método para instalar config.h debe ser el mismo que el método para destruir el sistema de archivos. Puede verter ácido en el disco duro o dejar caer la máquina en un edificio de 90 pisos o dejarla caer en un lago. Pero una mejor opción es no hacerlo. Config.h solo debe usarse en el directorio de compilación cuando compile su proyecto. No debe ser instalado. –

Respuesta

5

La macro ax_prefix_config_h parece lo que quiere. Proporciona una forma de crear otro archivo similar a config.h que contiene la información config.h con prefijo. Por lo tanto, por ejemplo, en lugar de #define HAVE_SOMETHING en config.h obtendrá #define MYLIB_HAVE_SOMETHING en mylib_config.h. Muy útil.

+0

Brillante! Gracias. – alternative

0

Puede enviar un archivo de configuración diferente cambiando la macro AC_OUTPUT, aunque no estoy seguro de cómo se va a integrar el proyecto con otros proyectos. Si es un subproyecto, entonces estará en un subdirectorio de todos modos.

2

No debe exportar config.h en la interfaz de su biblioteca de todos modos.

This link muestra un método para evitar que sus encabezados instalados realmente realmente deban depender de la plataforma. Sin embargo, es un método frágil que usa una macro de autoconf obsoleta.

Cuestiones relacionadas