Библиотека Autotools и управление выходными файлами объекта

Моя цель состоит в том, чтобы все объектные файлы, созданные в каталоге .objs, вместо корня Makefile и чтобы двоичные файлы (и библиотеки) были скопированы в каталог bin/. Но я не смог найти какие-либо ресурсы, чтобы объяснить, как это сделать. Как я могу это сделать?

Вот мой configure.ac и src/Makefile.am - У меня есть похожие файлы Makefile.am для двух разделяемых библиотек, на которые ссылаются. Они компилируются и после копирования их в каталог bin/работают так, как должны. Я просто пытаюсь автоматизировать этот процесс.

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

Итак, мой вопрос заключается в том, как указать выходные каталоги для компиляции результатов каждого Makefile (я хочу, чтобы они были скопированы в bin/, а для объектных файлов - в .obj каждого проекта, а не в корне файла Makefile.

Спасибо за помощь до сих пор.. этот сайт был отличным ресурсом, и я многое узнал из уже предоставленных ссылок.

Ответ 1

Система GNU Build System не использует каталоги obj/, поэтому автоутили не предназначены для поддержки этого.

Однако я могу придумать два способа обойти это.

Как установщик, вы можете создать любой пакет из его исходного каталога, набрав

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

Тогда любой выходной файл будет создан в каталоге builddir/. Эта схема компиляции позволяет скомпилировать исходный код, хранящийся в каталоге readonly (это стало еще более полезным в годы, когда FSF распространял компакт-диски с несжатым исходным кодом), или для компиляции одного и того же источника с разными настройками (или даже для различные архитектуры).

Как упаковщик, единственный способ заставить ваш пакет построить все в obj/ - это поставить Makefile.am в obj/ и объявить все свои правила сборки там. Это означало бы, что obj/Makefile.am выглядит следующим образом:

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

и т.д.. Я помню, что 10 лет назад POSE, эмулятор Palm OS, использовал настройку, подобную приведенной выше. Я не рекомендую его, так как он не поддерживается. Это действительно лучше придерживаться философии инструментов и использовать системы сборки, которые работают как другие пакеты GNU.

Для ознакомления с GNU Build System, я рекомендую прочитать введение руководства Automake: http://www.gnu.org/software/automake/manual/automake.html#GNU-Build-System

В частности, раздел "Служебные случаи". Если вам не нужны эти варианты использования, я думаю, что ваш лучший курс НЕ должен использовать Automake и создавать собственные Makefiles. В противном случае вы будете пытаться заставить Automake делать то, для чего он не предназначен, и вы быстро его ненавидите.

EDIT 2013-08-26. Обратите внимание, что проект Automake с использованием подкаталога с именем с использованием obj/ не переносится в BSD.

Ответ 1

Ответ 2