Re: Non-recursive makefiles

[Christopher S Morrison]

Apologies on the delayed reply, but I felt like taking the bait..

I respectfully and fully disagree that running make in a subdirectory is 
admission of anything other than a need to clean some a subset of a given 
project in a convenient manner.  The reason someone might want to do a make 
clean in a subdirectory could be for several reasons, the likely most prevalent 
reason that comes to mind is that the given project is a collection of more 
than one target product, i.e. it's a suite of stuff.  Changing to a directory 
is merely a convenient and practical selection/indication mechanism, one 
frequently used in other paradigms and one easily understood.

This collection could be potentially hundreds or even thousands of libraries, 
binaries, and other target products, all isolated and neatly self-contained 
into directories yet still belonging part of a larger collective distribution.  
Changing to a directory and running clean is not really any different than the 
prevalent GUI means of right-clicking said subproject in a graphical IDE 
environment and selecting clean from some drop-down menu.  For that matter, so 
are specific clean targets -- they both perform the same active of indicating a 
subproject (i.e. changing to the directory or providing some target naming 
convention) and an action (i.e. clean).

Sure, one could add create specific clean targets for all of the potential 
target products.  I could also compile everything by hand while I'm at it so 
why bother with a Makefile?  Just because custom clean targets _can_ be made in 
a higher level doesn't necessarily imply that running make clean in a 
subdirectory is bad or wrong and it's certainly not broken.  It's simply a 
different method to achieve the same end result.

Personally, if I have to add more than a couple custom make targets for 
something that could clearly be automated, then I'm wasting time as a 
developer.  Recursive rules conveniently have the ability to auto-generate 
those isolated subdir build rules, so my time is saved (I don't have to write a 
bunch of rules that can be autogenerated) as are developer users that work on 
isolated subsets of the project (and they don't have to remember or look up 
custom 'clean-whatever-monkey-poo' named targets ).

Now if automake generated some sort of "clean dirA-dirB-clean" rules like has 
been discussed here in the past, that would also be convenient and useful.  
That still would not have any implication on the functional utility or 
brokenness of a subdir clean, imho.  It would also simply just be a different 
method to achieve the same end result.

Cheers!
Sean


On Tuesday, May 30, 2006, at 10:23AM, Bob Friesenhahn <address@hidden> wrote:

>On Mon, 29 May 2006, Stefan Puiu wrote:
>> However, people haven't mentioned yet the main point in Peter Miller's
>> paper - dependency handling, which I think is very important (I would
>> say significantly more important than the ability to type "make clean"
>> in one directory). Most people I work with are more familiar with
>
>There should be no need to type "make clean" in a subdirectory.  Doing 
>so is a rank admission that the build system is broken.  Why else 
>would someone want to do a "make clean" in a subdirectory?  Perhaps 
>the desire to do "make clean" in a subdirectory is aquired bad 
>behavior?
>
>That said, if one inspects the Automake generated Makefile, it does 
>not take long to learn how to create specific clean targets which will 
>work for a specific target.
>
>Bob
>======================================
>Bob Friesenhahn
>address@hidden, http://www.simplesystems.org/users/bfriesen/
>GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
>
>