[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Non-recursive makefiles
Christopher S Morrison
Re: Non-recursive makefiles
Fri, 30 Jun 2006 10:22:47 -0700
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.
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
>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.
>GraphicsMagick Maintainer, http://www.GraphicsMagick.org/