RE: Using convenience libraries with non-recursive make

[John Calcote]

Hi Del,

First, if you're building a pure convenience library (you don't want shared
objects), then save yourself a layer of complexity by removing libtool from
the equation - just use LIBRARIES instead of LTLIBRARIES in your Makefile.am
file. Second, make sure all your relative paths are correct - that's often
the problem with errors like this.

Regards,
John

> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden On Behalf Of
> Del Merritt
> Sent: Wednesday, August 15, 2012 9:27 AM
> To: address@hidden
> Subject: Using convenience libraries with non-recursive make
> 
> I'm using automake 1.11.1 and autoconf 2.68.  I am switching from a set of
> hand-written Makefiles to autoconf/automake.  I'm switching to autotools
> since the support for cross-compilation is already there; my hand-written
> Makefiles are getting hard to manage, and they don't support VPATH builds
> cleanly.
> 
> I have a lot of source files (4K+) and a lot of libraries (40+).  My goal
is to
> generate a single (typically/initially static) library and an executable
that
> demos/drives it.  I am hoping to avoid a recursive make (SUBDIRS=...),
since I
> am holding to the "Recursive makefiles considered harmful" mantra.
> 
> A representative Makefile.am for my project is:
> 
>     # Automake rules to build application.
>     AM_CXXFLAGS = -I${includedir}
>     ACLOCAL_AMFLAGS = -I m4
>     bin_PROGRAMS = myprog
>     myprog_SOURCES = b/c/d/myprog__main.cpp
>     myprog_LDADD = libmyprog.la
>     lib_LTLIBRARIES = libmyprog.la
>     nodist_EXTRA_libmyprog_la_SOURCES = dummy.cxx
> 
>     lib_LTLIBRARIES += liba_s1.la libb_s2.la libb_c_s3.la
libb_c_d_myprog.la
> 
>     libmyprog_la_LIBADD =  liba_s1.la libb_s2.la libb_c_s3.la
>     libb_c_d_myprog.la
>     liba_s1_la_SOURCES = a/s1.cpp
>     libb_s2_la_SOURCES = b/s2.cpp
>     libb_c_s3_la_SOURCES = b/c/s3.cpp
>     libb_c_d_myprog_la_SOURCES = b/c/d/myprog.cpp
> 
> And it's similarly-simple configure.ac:
> 
>     AC_PREREQ([2.59])
>     AC_INIT([libmyprog], [1.0], address@hidden)
>     AM_INIT_AUTOMAKE([foreign subdir-objects])
>     AC_CONFIG_SRCDIR([a/s1.cpp])
>     AC_CONFIG_HEADERS([libmyprogconfig.h])
>     AC_CONFIG_MACRO_DIR([m4])
>     AC_PROG_MKDIR_P
>     AC_PROG_CXX
>     AM_PROG_LIBTOOL
>     AC_CONFIG_FILES([Makefile])
>     AC_OUTPUT
> 
> The directory structure is similar to:
> 
>     ./a/s1.cpp
>     ./b/s2.cpp
>     ./b/c/d/myprog.cpp
>     ./b/c/d/myprog__main.cpp
>     ./b/c/s3.cpp
> 
> and in my real project there's lots more source in each subdirectory, and
lots
> more nested subdirectories.  Yes, the source containing main() is down
deep
> in the structure; myprog.cpp instances some top-level classes, and
> myprog_main.cpp is just the main() that gets things rolling.
> 
> When ./configure and make, I get:
> 
>     address@hidden ~/am $ make
>     make  all-am
>     make[1]: Entering directory `/home/del/am'
>     make[1]: *** No rule to make target `libmyprog.lo', needed by
>     `libmyprog.la'.  Stop.
>     make[1]: Leaving directory `/home/del/am'
>     make: *** [all] Error 2
> 
> With the legacy hand-written makefile my project builds just fine.  I'm
> looking for suggestions as to what I'm missing in my Makefile.am.  Note
that I
> can explicitly say:
> 
>     $ make libb_c_s3.la
> 
> and I lo, that library's source(s) compile and link.  So part of the
generated
> Makefile is cool.
> 
> Thanks,
> -Del