Question

When I move some subdirectory away from project managed by “./configure” and all that things, it tries to get to some “../../configure.ac” and other things and is not easily buildable.

How to extract part of such project and make it independent?

Answer 1

There is two ways to deal with this, create a separate auto-tools build process or do away with the auto-tools and hand code or make a new Makefile.

myprojectfoo
   |
   +-- src
   |
   +-- man
   |
   +-- messages
   |
   +-- lib
   |
   +-- include
   |
   +-- others

Have a look at the illustration above, for a fictitious project called myprojectfoo and is using auto-tools to build a binary called foo. The top-level directory i.e. myprojectfoo will have configure.ac, Makefile.am and Makefile.in, in the subdirectories there would be at least Makefile.am and Makefile.in. The auto-tools will create and execute the make commands to build the project.

Now, from what I’m understanding in what you are trying to do:

myprojectfoo
   |   \ /
   +-- sXc
   |   / \
   +-- man
   |
   +-- messages
   |
   +-- lib
   |     \ /
   +-- incXude
   |     / \
   +-- others

You want to take out the src subdirectory and it’s include's also. Then in that case, it would be easier to create a separate Makefile (read – no auto-tools) build.. in that case, it would be easier.

The best way I can think of it is, you will have to make that decision ultimately, how big is the subset of the project’s sources you want to extract, once you go ahead with that, remove all references to Makefile.am, Makefile.in… and borrow an existing simple Makefile template to build it and invoke it like this

make -f MyMakefile

OR

If you want to build a separate project using that subset using auto-tools:

1. Create a bare-bones Makefile.am as shown below.
2. Create a bare-bones configure.ac as shown below…
3. Run autoscan on the source to pick out the dependencies, add the results of the output file ‘configure.scan’ to the configure.ac
4. Run automake (Do this once!)
5. Run autoconf then. It may complain about missing files such as INSTALL, COPYING etc
6. Then any subsequent changes to configure.ac, run autoreconf after that, which will execute automake, autoconf, and other supporting auto-tools programs.

Taking a sample of the Makefile.am for Linux…

SUBDIRS = src include
ACLOCAL_AMFLAGS = -I m4

Taking a sample of the configure.ac for Linux…

AC_PREREQ(2.63)

AC_INIT([mysubsetprojectfoo], [0.1a], [[e-mail]])
AC_CONFIG_AUX_DIR([build-aux])

AM_INIT_AUTOMAKE([-Wall -Werror])
AM_GNU_GETTEXT_VERSION([0.17])
AM_GNU_GETTEXT([external])
AM_CFLAGS=
# Checks for programs.
AC_HEADER_STDC
AC_PROG_CC

AC_ARG_ENABLE([debug],
[  --enable-debug               Turn on debugging],
[case "${enableval}" in
  yes) debug=true ;;
  no)  debug=false ;;
  *) AC_MSG_ERROR([bad value ${enableval} for --enable-debug]) ;;
esac],[debug=false])
AM_CONDITIONAL([DEBUG], [test x$debug = xtrue])
# Checks for libraries.
AC_CHECK_LIB([mylib], [mylib_function], [:])
if test "$mylib" = :; then
        AC_MSG_ERROR([MyLib is missing.\
                                  This can be downloaded from 'http://www.foo.baz'])
fi
AC_CONFIG_HEADERS([config.h])

# Checks for header files. 
# FROM running 'autoscan' on the source directory
AC_CHECK_HEADERS([arpa/inet.h fcntl.h libintl.h locale.h netinet/in.h stdlib.h string.h sys/ioctl.h sys/socket.h syslog.h unistd.h])

# Checks for typedefs, structures, and compiler characteristics.
AC_C_INLINE
AC_C_CONST
AC_TYPE_SIGNAL
AC_TYPE_PID_T
AC_TYPE_UID_T
AC_TYPE_SIZE_T

# Checks for library functions.
AC_FUNC_FORK
AC_FUNC_MALLOC
AC_CHECK_FUNCS([atexit inet_ntoa memset regcomp socket strdup strerror])

AC_CONFIG_FILES([Makefile src/Makefile include/Makefile])
AC_OUTPUT

The commands for the auto-tools, is top of my head and I may have missed something..feel free to point out by placing a comment on this at the bottom of this post and it will be amended accordingly.