2009-06-18 9 views
6

Mi objetivo es tener todos los archivos de objeto construidos en un directorio .objs en lugar de la raíz del Makefile, y tener los binarios (y bibliotecas) copiados en el directorio del proyecto bin/ . Pero no he podido encontrar ningún recurso para explicar cómo hacer esto. ¿Cómo voy a hacer esto?Librería Autotools y control de salida de archivo de objeto

Aquí está mi configure.ac y src/Makefile.am - Tengo archivos similares Makefile.am para dos bibliotecas compartidas a las que se hace referencia. Compilan y, después de copiarlos en el directorio bin/, funcionan como deberían. Solo estoy buscando automatizar este proceso.

configure.ac

AC_PREREQ([2.63]) 
AC_INIT([gtkworkbook], [0.12], [[email protected]]) 
AC_CONFIG_SRCDIR([gtkworkbook/cell.c]) 
AM_INIT_AUTOMAKE([gtkworkbook], [0.12]) 

# Checks for programs. 
AC_PROG_CXX 
AC_PROG_CC 
AC_PROG_INSTALL 
AC_PROG_MAKE_SET 
AC_PROG_RANLIB 
AC_PROG_LIBTOOL 
AC_PROG_CC_C_O 

AC_CHECK_LIB([pthread], [pthread_mutex_init], [], [ 
      echo "pthread library is missing. pthread is required for this program" 
      exit -1]) 

# Checks for header files. 
AC_CHECK_HEADERS([arpa/inet.h netdb.h netinet/in.h stdlib.h string.h sys/socket.h unistd.h]) 

# Checks for typedefs, structures, and compiler characteristics. 
AC_HEADER_STDBOOL 
AC_C_INLINE 
AC_TYPE_SIZE_T 

# Checks for library functions. 
AC_CHECK_FUNCS([gethostbyname memset socket]) 

AC_OUTPUT([Makefile 
     csv/Makefile 
     gtkworkbook/Makefile 
     src/Makefile]) 

src/Makefile.am

AUTOMAKE_OPTIONS= foreign 

C_FLAGS= -I/usr/local/include -I/usr/include -I/usr/local/include/gtkextra-2.0 -I$(top_srcdir)/include `pkg-config gtk+-2.0 glib-2.0 --cflags` 
L_FLAGS= -L/usr/local/lib -L/usr/lib -L$(top_srcdir)/lib `pkg-config gtk+-2.0 glib-2.0 --libs` -lgtkextra-x11-2.0 

bin_PROGRAMS= gtkworkbook 
gtkworkbook_SOURCES= application.c config.c main.c parse.c plugin.c 
gtkworkbook_CFLAGS= -Wall -lgthread-2.0 -std=c99 $(C_FLAGS) 
gtkworkbook_LFLAGS= -ldl $(L_FLAGS) 
gtkworkbook_LDFLAGS= $(L_FLAGS) 
gtkworkbook_LDADD= ../gtkworkbook/libgtkworkbook.la ../csv/libcsv.la 

lib_LTLIBRARIES= realtime.la 
realtime_la_SOURCES= realtime/CsvParser.cpp realtime/Network.cpp realtime/Packet.cpp realtime/plugin_main.cpp \ 
    realtime/thread_main.cpp realtime/concurrent/Mutex.cpp realtime/concurrent/Semaphore.cpp \ 
    realtime/concurrent/Thread.cpp realtime/concurrent/ThreadGroup.cpp realtime/concurrent/ThreadPool.cpp \ 
    realtime/proactor/Dispatcher.cpp realtime/proactor/Event.cpp realtime/proactor/Proactor.cpp \ 
    realtime/proactor/InputDispatcher.cpp realtime/proactor/Worker.cpp realtime/network/Tcp.cpp 
realtime_la_CPPFLAGS= -Wall -Wno-write-strings $(C_FLAGS) 
realtime_la_LFLAGS= -lgtkworkbook -lcsv $(L_FLAGS) 
realtime_la_LDFLAGS= -module -export-dynamic 
realtime_la_LIBADD= ../gtkworkbook/libgtkworkbook.la ../csv/libcsv.la 

lo tanto, mi pregunta es cómo especificar los directorios de salida de los resultados de compilación de cada Makefile (I desear que se copien en bin/, y para que los archivos de objeto estén en .obj de cada pro ject en lugar de en la raíz del Makefile.

Gracias por la ayuda hasta el momento .. este sitio web ha sido un gran recurso, y he aprendido mucho de los enlaces provistos ya.

Respuesta

10

El sistema de compilación GNU no utiliza los directorios obj/, por lo que las autotools no están diseñadas para admitir eso.

Sin embargo, puedo pensar en dos formas de evitar esto.

Como instalador, se puede construir cualquier paquete fuera de su directorio de origen escribiendo

mkdir builddir 
cd builddir 
../path-to-sourcedir/configure 
make 

Entonces, cualquier archivo de salida se crea en el directorio builddir/. Este esquema de compilación permite compilar el código fuente guardado en un directorio de solo lectura (esto tenía más sentido en los años en que la FSF distribuía CD con código fuente sin comprimir), o compilar la misma fuente con diferentes configuraciones (o incluso diferentes arquitecturas).

Como envasador, la única forma en que podría forzar su paquete para construir todo en obj/ es poner su Makefile.am en obj/, y declarar todas sus reglas de generación allí. Esto significaría un obj/Makefile.am mirando como:

bin_PROGRAMS = foo bar 
foo_SOURCES = ../src/foo/main.c ../src/foo/help.c ../src/foo/list.c 
bar_SOURCES = ../src/bar/bar.c 

etc. Recuerdo que hace 10 años, postura, el emulador de Palm OS, se utiliza una configuración como la anterior. No lo recomiendo, ya que no es realmente sostenible. Realmente es mejor seguir con la filosofía de las herramientas y usar un sistema de compilación que funcione como los otros paquetes de GNU.

Para una introducción a la construcción del sistema GNU, recomiendo leer la introducción del manual Automake: http://www.gnu.org/software/automake/manual/automake.html#GNU-Build-System

Especialmente la sección de casos de uso. Si no le importan estos casos de uso, creo que su mejor opción es NO utilizar Automake y crear sus propios Makefiles. De lo contrario, seguirás tratando de forzar a Automake a hacer algo para lo que no está diseñado, y lo odiarás rápidamente.

EDITAR 2013-08-26: Tenga en cuenta que un proyecto de Automake que utiliza un subdirectorio llamado using obj/ is not portable a BSD.

0

La forma más fácil de hacerlo sería establecer "libdir" en el directorio en el que desea que terminen estos archivos, y utilizar el destino de instalación para copiarlos allí.

Esto le impediría utilizar el objetivo de instalación en el sentido convencional.

+0

Esto no es algo que pueda anularse mediante la línea de comandos de configuración? –

Cuestiones relacionadas