Stefano Lattarini <stefano.lattar...@gmail.com> 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 -- 永日の 澄んだ紺から 永遠へ
