Recursive Make Considered Harmful (OT?)

Michael Turner <>
Tue Dec 15 11:14:51 CET 2009



On 12/15/2009, "Bengt Kleberg" <> wrote:

>Perhaps I am  mistaken, but I think the solution presented in the paper,
>while being better than recursive make, is cumbersome and fragile. So I
>would say that make is lacking, once the project leaves a single
>directory.

What do you mean by "leaves a single directory?"  The only
interpretation I can think of is: "has source files in more than one
directory."  Whatever the demerits of the approach suggested, it's
clearly not limited to single-directory builds.  It's a way to have one
big makefile (composed of some fragments of makefiles in subdirectories)
for something you're building in several directories.

>From the beginning of the Implementation Notes:

"The most basic problem to overcome when implementing single-session
make is to avoid flattening your directory structure, while joining the
dependency information present in each subdirectory in a single tree."

So what did you mean by "leaves a single directory"?

-michael turner

>On Mon, 2009-12-14 at 13:07 -0500, Toby Thain wrote:
>> On 14-Dec-09, at 5:47 AM, Michael Turner wrote:
>>
>> >
>> > http://miller.emu.id.au/pmiller/books/rmch/
>> >
>> > Thanks for this.  I wasn't on the list when you first mentioned this
>> > paper. I vaguely remembered just such a paper while trying to build an
>> > Erlang release a few months ago.  It struck me as a breath of fresh
>> > air
>> > when I first read it over a decade ago.
>> >
>> > It's not so much that "make" is lacking, I think.
>>
>> Right, the problem isn't with 'make' per se, which the paper serves
>> to prove.
>>
>> --Toby
>>
>> > Mainly it's that
>> > the obvious approach (recursion) for building stuff out of a
>> > hierarchical directory structure is not necessarily the best way if
>> > you're using make.
>> >
>> > Having one big makefile seems, of course, horribly inelegant.  But
>> > when
>> > I've tried that approach, it always reminds me of things I'd forgotten
>> > while using big, lumbering, recursive build systems.  Like, make is
>> > really fast.  Compilers are pretty fast, too.  And having
>> > everything in
>> > one place can be nice.
>> >
>> > -michael turner
>> >
>> > On 12/14/2009, "Bengt Kleberg" <> wrote:
>> >
>> >> Greetings,
>> >>
>> >> It has been well over a year since last time I mentioned this paper
>> >> "Recursive Make Considered Harmful",
>> >> (http://miller.emu.id.au/pmiller/books/rmch/). so I hope it is ok
>> >> that I
>> >> do it again.
>> >>
>> >> Nice little reading for those that find themselves wondering if
>> >> they are
>> >> the only ones that think make is somewhat lacking, at times.
>> >>
>> >>
>> >> bengt
>> >>
>> >> On Mon, 2009-12-14 at 13:02 +0300, Sergei Golovan wrote:
>> >>> Hi!
>> >>>
>> >>> I did some further investigations and found that simply calling make
>> >>> in all doc/src
>> >>> directories works better then trying to run make recursively.
>> >>>
>> >>> pwd=`pwd`
>> >>> for i in `find . -wholename '*/doc/src'` ; do
>> >>>     (cd $i ; make man ERL_TOP=$pwd )
>> >>> done
>> >>>
>> >>> (using Erlang R12B-02-1 edoc and docbuilder, and the attached
>> >>> docb_gen script)
>> >>> generates manpages perfectly, make html and make pdf though
>> >>> suffer from runtime
>> >>> errors while running xsltproc.
>> >>>
>> >>> Running make recursively reveals a whole bunch of problems with
>> >>> missing and redefined
>> >>> 'docs' targets in makefiles.
>> >>>
>> >>> On Mon, Dec 14, 2009 at 12:16 PM,  <> wrote:
>> >>>> Hi Sergei,
>> >>>> we started to build our documentation with open source tools in
>> >>>> R13B03 so it
>> >>>> would be possible to build the doc from the delivered sources.
>> >>>>
>> >>>> But it's still only built in house because we hadn't time to
>> >>>> test it but the plan is
>> >>>> to have it work for everyone in R13B04.
>> >>>>
>> >>>> Thanks for your report, we'll have a look at those fault.
>> >>>>
>> >>>> Regards Lars
>> >>>>
>> >>>>
>> >>>> Sergei Golovan wrote:
>> >>>>> Hi!
>> >>>>>
>> >>>>> I'm trying to build Erlang documentation from the sources (the
>> >>>>> goal is
>> >>>>> to switch from prebuilt docs for Debian Erlang packages as
>> >>>>> building
>> >>>>> them from the source is preferable).
>> >>>>>
>> >>>>> To do that I run
>> >>>>> make
>> >>>>> make TYPE=docs
>> >>>>> (in fact, make libs doesn't recognize TYPE, so I had to replace
>> >>>>> "make
>> >>>>> opt" by "make $(TYPE) in the top-level Makefile).
>> >>>>>
>> >>>>> and I've found several problems which make build fail:
>> >>>>>
>> >>>>> 1) For some XML files (e.g. erts/docs/src/book.xml) xsltproc
>> >>>>> reports
>> >>>>> runtime errors about undefined variables (partnum in line 871
>> >>>>> and 963
>> >>>>> of db_pdf.xsl, in lines 1075 and 1173 of db_html.xsl). Is this
>> >>>>> a bug
>> >>>>> in the stylesheets or in xsltproc? (Both 1.1.24 from Debian
>> >>>>> stable and
>> >>>>> 1.1.26 from Debian unstable failed.)
>> >>>>>
>> >>>>> 2) wx application has duplicated targets html and docs in its
>> >>>>> makefile.
>> >>>>>
>> >>>>> 3) wx application (and others too) require docb_gen script to
>> >>>>> generate
>> >>>>> XML docs sources. It is missing. (I suppose that it is a simple
>> >>>>> wrapper around docb_gen Erlang module and could be recreated,
>> >>>>> but It'd
>> >>>>> be better if it were shipped in Erlang sources.)
>> >>>>>
>> >>>>> Is Erlang documentation supposed to be buildable from the
>> >>>>> source, or
>> >>>>> it still requires some unavailable tools?
>> >>>>>
>> >>>>> Cheers!
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> ________________________________________________________________
>> >>> erlang-bugs mailing list. See http://www.erlang.org/faq.html
>> >>> erlang-bugs (at) erlang.org
>> >>
>> >>
>> >> ________________________________________________________________
>> >> erlang-bugs mailing list. See http://www.erlang.org/faq.html
>> >> erlang-bugs (at) erlang.org
>> >>
>> >>
>> >
>> > ________________________________________________________________
>> > erlang-bugs mailing list. See http://www.erlang.org/faq.html
>> > erlang-bugs (at) erlang.org
>> >
>>
>
>
>________________________________________________________________
>erlang-bugs mailing list. See http://www.erlang.org/faq.html
>erlang-bugs (at) erlang.org
>
>


More information about the erlang-bugs mailing list