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: automake-bounces+john.calcote=gmail....@gnu.org > [mailto:automake-bounces+john.calcote=gmail....@gnu.org] On Behalf Of > Del Merritt > Sent: Wednesday, August 15, 2012 9:27 AM > To: automake@gnu.org > 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], [d...@alum.mit.edu]) > 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: > > del@oyster ~/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
