Re: Issues with subdir-objects and differing versions of automake

[Miles Bader]

Stefano Lattarini <address@hidden> writes:
> It seems to me that the situation there has improved a lot in the
> recent years, to the point that recursive and non-recursive build
> support is almost on-par (and the non-recursive option is the
> recommended one).  Or are you referring to documentation issues rather
> the coding/design ones?

Well I suppose it could entirely be a documentation issue (or an "I'm
just blind/stupid" issue :) ... even the best support in the world
can't help you if you don't know about it ... :]

I have searched a little bit for people's automake-based non-recursive
solutions, and the impression I've gotten is that while it's certainly
doable, it's more fiddly and less straight-forward than the
traditional recursive method.  [I'm also using Debian unstable's
automake (v 1.13.3), so I can't easily use features that are only in
very recent automake versions, e.g. %reldir%.]

In part this is because automake makes recursive makefiles _so_ easy
and clean -- all you have to do is provide SUBDIRS, and then you get a
per-directory local space to play in, and can just write your
Makefile.am "locally" without worrying about other directories except
when you want to.

With non-recursive Makefiles, on the other hand, you have a single
global namespace, even if you split the actual rules into included
per-subdirectory Makefile.am fragments.  Like all global namespaces,
this means you need to worry about conflicts and interactions etc, and
need to write everything from a global perspective.

In particular:

1. Even when make-fragments are physically located in subdirectories,
   their rules still need to state everything "globally", e.g., one
   must write "libblargh_a_SOURCES = blargh/file1.c blargh/file1.c..."
   Not a huge deal for very small libraries, but decidedly bloated if
   there are 50 files in a library.  This hold for pretty much every rule...
   [If one has access to newer versions of automake, one can write e.g.
   "%D%/file1.c" instead, but this is still pretty cumbersome and
   ugly.]

2. You can't just change AM_CFLAGS to add special changes appropriate
   for a subdirectory, you need to use per-library CFLAGS, which comes
   with its own annoyances.  In particular, it results in ugly
   prefixes being added to the names of .o files even when not
   necessary... my .o file names end up being like 25 characters long
   as a result!

None of this is _fatal_, it's still obviously possible to just bite
the bullet, jump through the hoops, and get a working non-recursive
build -- but neither is it particularly nice...

One of automake's great strengths, traditionally, is the ability it
gives one to write straight-forward and highly readable/maintainable
Makefile.ams, without all the boilerplate and nonsense required for
traditional Makefiles.  However using the non-recursive style with
current automake seems in some ways a step backwards, requiring more
boilerplate and more fiddliness, ceding some of automake's traditional
advantages...

When I recently completely revamped my project's source tree, I opted
for subdirectories with traditional recursive automake -- it was just
so _easy_, whereas non-recursive automake, well, that seemed to
require thought and care.  I hope I can switch to non-recursive style
in the future when I have some time to play with it, but it seems less
straight-forward and more work.

As for how to _address_ these issues, I dunno, ... ideally, I'd like
to be able to "think locally" when writing a subdirectory Makefile.am,
even if the final build mechanism ends up being a single global
Makefile.  Maybe it's too hard to fully automate that, but still,
better tools for writing Makefile.am fragments would still be useful.
E.g., "automatically add %RELDIR% to all relative filenames in this
[Makefile.am fragment] file", and maybe cleaning up library-CFLAGS to
get rid of the need for prefixes (If I'm using subdir-objs anyway, why
should I need prefixes?!).

-miles

-- 
永日の　澄んだ紺から　永遠へ