Re: [PATCH] maint: remove most recursion in automake's own build system

[Jim Meyering]

Stefano Lattarini wrote:
> On 04/05/2012 03:55 PM, Jim Meyering wrote:
>>
>> I am glad to see that you too are taking an interest in non-recursive make.
>> I've always liked how bison switched to non-recursive make, and recently
>> converted cppi to do the same (the final hold-out there is po/, since its
>> Makefile.in.in is automatically generated).
>>
>> Did you consider leaving doc-related Makefile.am parts in say,
>> doc/local.mk, which could then be included from the top-level
>> Makefile.am, and similarly for lib/ and m4/?
>>
> Yes, I thought about that, but in the end I find such a separation somewhat
> artificial and confusing.  In addition, keeping all rules and variables
> defined in a single Makefile makes it easier to spot code duplication and
> devise possible refactoring.

With a small project it makes little difference, I guess, but
read on...

>> I find that to be more maintainable in that it keeps the
>> rules in the same directory as the associated files, and the
>> top-level Makefile.am does not become quite so large.
>>
> I think we'll have to "agree to disagree" on this; in fact, I find your
> suggested setup less maintainable, since, as I've hinted above, it entails
> what looks to me as an artificial separation -- artificial because make
> does not allow a real incapsulation/modularity anyway, so it's better be
> "honest" and use a monolithic Makefile right away.

I'd say it's more about locality and modularity than "honesty" ;-)
Think of a project with many sub-directories or with
a few directories that are two or more levels deep.

With your approach, any file renaming, addition or deletion anywhere leads
to a change in the top-level Makefile.am, making that file a potential
bottleneck and a more-likely source of conflicts.  Keeping the file name
lists near the actual files is more scalable because it reduces that
cost/risk.  IMHO, automake should set a good example on this front:
an example that would be useful to more projects.

> Do you still think my patch is a worthwhile move even in light of this
> disagreement, or do you think it's better to keep the status quo?

Yes, but I haven't given up.