Re: Using convenience libraries with non-recursive make

[Del Merritt]

On 08/22/2012 07:12 PM, Bob Friesenhahn wrote:
> On Wed, 22 Aug 2012, Del Merritt wrote:
> > [Reponding on-list to what was Diego's private response to me; I hope 
> > he doesn't mind.]
> >
> > I just finished an experiment with a single libfoo.a and all 
> > many-thousands of sources for libfoo_a_SOURCES.  The compilation 
> > worked, but I got the dreaded "make[1]: execvp: /bin/bash: Argument 
> > list too long" message when it tried to do the "ar".  To the shell's 
> > credit, the command line appears to be 134K bytes/characters in 
> > length, so I can understand why it would choke. This doesn't bode 
> > well for the various "dist" targets.
>
> In case it is not clear, when a libtool convenience library is used, 
> all of the object files are extracted from the .a file and then the 
> object files are passed to the linker.  If you were to successfully 
> build the archive, the doom might just be postponed to the link step.

This was my concern.  And in fact it is why my original hand-build 
makefiles created libraries instead of a single mass of source and the 
resultant ".o" files.

> In a non-recursive build, it really should be better to simply 
> encapsulate the collections of objects to use (equivalent to a 
> convenience library) into make variables and then tell automake to use 
> those when the dependent libraries or executables get built.
>
> Libtool is supposed to take steps to limit command line length to the 
> tested limits.  Apparently this did not work for you.

Nope, and as noted earlier in this thread, the dist targets were seeing 
the line-too-long issue from the start.

I am a little surprised that this problem isn't more common for "large" 
projects.  In my particular project, I *could* make each subdirectory 
more independent with its own makefile.  But in the spirit of "Recursive 
make considered harmful", I see either a loss in dependency checking or 
increased complexity, along with build order concerns, since each 
subdirectory really doesn't stand on its own.

I had opted for libtool in part because I hope to eventually support a 
shared library option and in part because it gives me "--enable-static" 
and "--disable-shared" as "free" options to configure.  This is 
important for my builds since I use other, external (3rd party) 
autoconf-controlled packages.

I'm still hoping for some collective wisdom on how to wrangle the large 
set of files that comprise my project.

Thanks,
-Del