How to suppress 'Entering/Leaving ...' messages while running make? - Unix

This is a discussion on How to suppress 'Entering/Leaving ...' messages while running make? - Unix ; Hi All, I'd like to know how can I suppress 'Entering/Leaving ...' messages while running make. This should be easy. But I can't find it in the man page. Best Regards, PRC Apr 28, 2008...

+ Reply to Thread
Results 1 to 11 of 11

Thread: How to suppress 'Entering/Leaving ...' messages while running make?

  1. How to suppress 'Entering/Leaving ...' messages while running make?

    Hi All,

    I'd like to know how can I suppress 'Entering/Leaving ...' messages
    while running make. This should be easy. But I can't find it in the
    man page.

    Best Regards,
    PRC
    Apr 28, 2008

  2. Re: How to suppress 'Entering/Leaving ...' messages while running make?

    PRC writes:

    > Hi All,
    >
    > I'd like to know how can I suppress 'Entering/Leaving ...' messages
    > while running make. This should be easy. But I can't find it in the
    > man page.


    If you suppress them, how will you know what directory errors pertain
    to?

    My advice is to write your makefiles non-recursively. Not only will
    get rid of those messages, make will run faster and do a better job.
    Peter Miller has written an excellent paper on the subject:
    http://miller.emu.id.au/pmiller/books/rmch/

    --
    Måns Rullgård
    mans@mansr.com

  3. Re: How to suppress 'Entering/Leaving ...' messages while runningmake?

    PRC wrote:
    > Hi All,
    >
    > I'd like to know how can I suppress 'Entering/Leaving ...' messages
    > while running make. This should be easy. But I can't find it in the
    > man page.


    You have it backwards. There is a flag which tells (GNU) make to print
    the entering/leaving messages; it is not the default behavior. The flag
    may be -C but you should look it up.

    RM

  4. Re: How to suppress 'Entering/Leaving ...' messages while runningmake?

    Rex Mottram wrote:
    > PRC wrote:
    >> Hi All,
    >>
    >> I'd like to know how can I suppress 'Entering/Leaving ...' messages
    >> while running make. This should be easy. But I can't find it in the
    >> man page.

    >
    > You have it backwards. There is a flag which tells (GNU) make to print
    > the entering/leaving messages; it is not the default behavior. The flag
    > may be -C but you should look it up.


    The flag is actually -w aka --print-directory. There is also a
    --no-print-directory flag.

  5. Re: How to suppress 'Entering/Leaving ...' messages while running make?

    PRC writes:
    >Hi All,
    >
    >I'd like to know how can I suppress 'Entering/Leaving ...' messages
    >while running make. This should be easy. But I can't find it in the
    >man page.
    >
    >Best Regards,
    >PRC
    >Apr 28, 2008


    make --no-print-directory

  6. Re: How to suppress 'Entering/Leaving ...' messages while runningmake?

    On Apr 28, 2:18 am, Måns Rullgård wrote:

    > My advice is to write your makefiles non-recursively. Not only will
    > get rid of those messages, make will run faster and do a better job.
    > Peter Miller has written an excellent paper on the subject:http://miller.emu.id.au/pmiller/books/rmch/


    At the risk of writing a me-too post, I'd like to second this post in
    the strongest possible way.

    It is well worth reading the paper given ("Recursive Make Considered
    Harmful", if you didn't already know).

    Just a cople of personal observations as well (some duplication with
    the paper):

    It's harder to get dependencies resolved correctly in recursive
    makefiles. This makes make -j 4 break. As multi CPU computers become
    ubiquitous, is is much more important that this works.

    I find it much harder to fix build system bugs in recursive makefiles,
    (especially if they are mechanically generated), since you often don't
    know which makefiles you have to change flags in to get it to build.

    -Ed

    --
    (You can't go wrong with psycho-rats.)(http://mi.eng.cam.ac.uk/~er258)

    /d{def}def/f{/Times s selectfont}d/s{11}d/r{roll}d f 2/m{moveto}d -1
    r 230 350 m 0 1 179{ 1 index show 88 rotate 4 mul 0 rmoveto}for/s 12
    d f pop 235 420 translate 0 0 moveto 1 2 scale show showpage

  7. Re: How to suppress 'Entering/Leaving ...' messages while running make?

    Edward Rosten writes:
    >On Apr 28, 2:18 am, M=E5ns Rullg=E5rd wrote:
    >
    >> My advice is to write your makefiles non-recursively. Not only will
    >> get rid of those messages, make will run faster and do a better job.
    >> Peter Miller has written an excellent paper on the subject:http://miller.e=

    >mu.id.au/pmiller/books/rmch/
    >
    >At the risk of writing a me-too post, I'd like to second this post in
    >the strongest possible way.
    >
    >It is well worth reading the paper given ("Recursive Make Considered
    >Harmful", if you didn't already know).
    >
    >Just a cople of personal observations as well (some duplication with
    >the paper):
    >
    >It's harder to get dependencies resolved correctly in recursive
    >makefiles. This makes make -j 4 break. As multi CPU computers become
    >ubiquitous, is is much more important that this works.
    >
    >I find it much harder to fix build system bugs in recursive makefiles,
    >(especially if they are mechanically generated), since you often don't
    >know which makefiles you have to change flags in to get it to build.
    >


    Which implies that the makefiles were poorly designed. It's quite
    possible to centralize both rules and definitions (flags) in one or two
    top level files which are included by all recursive makefiles.

    Recursive makefiles also have their advantages, particularly in large
    projects where builds at the sub-directory level are useful.

    I disagree with the parallelism (-j4) concern, as properly designed makefiles
    only have interdependecies higher in the tree, and elements at the same
    level of the tree should be able to proceed in parallel, however it
    is a simple matter to order targets that are dependent upon another
    at the same level such they they can, where allowed, execute in parallel.

    If there are problems in mechanically generated makefiles (I assume you're
    referring to those built by autoconf), then the generator (or the data
    source (automake files)) need to be fixed, not the makefiles themselves.
    This holds for imake as well as autoconf.

    scott

  8. Re: How to suppress 'Entering/Leaving ...' messages while running make?

    In scott@slp53.sl.home (Scott Lurndal) writes:

    > Recursive makefiles also have their advantages, particularly in large
    > projects where builds at the sub-directory level are useful.


    As the paper points out, a single Makefile is perfectly capable of doing
    this. Just use "make subtarget" instead of "make".

    --
    John Gordon A is for Amy, who fell down the stairs
    gordon@panix.com B is for Basil, assaulted by bears
    -- Edward Gorey, "The Gashlycrumb Tinies"


  9. Re: How to suppress 'Entering/Leaving ...' messages while running make?

    On Wed, 30 Apr 2008 21:16:34 GMT Scott Lurndal wrote:
    | Edward Rosten writes:
    |>On Apr 28, 2:18 am, M=E5ns Rullg=E5rd wrote:
    |>
    |>> My advice is to write your makefiles non-recursively. Not only will
    |>> get rid of those messages, make will run faster and do a better job.
    |>> Peter Miller has written an excellent paper on the subject:http://miller.e=
    |>mu.id.au/pmiller/books/rmch/
    |>
    |>At the risk of writing a me-too post, I'd like to second this post in
    |>the strongest possible way.
    |>
    |>It is well worth reading the paper given ("Recursive Make Considered
    |>Harmful", if you didn't already know).
    |>
    |>Just a cople of personal observations as well (some duplication with
    |>the paper):
    |>
    |>It's harder to get dependencies resolved correctly in recursive
    |>makefiles. This makes make -j 4 break. As multi CPU computers become
    |>ubiquitous, is is much more important that this works.
    |>
    |>I find it much harder to fix build system bugs in recursive makefiles,
    |>(especially if they are mechanically generated), since you often don't
    |>know which makefiles you have to change flags in to get it to build.
    |>
    |
    | Which implies that the makefiles were poorly designed. It's quite
    | possible to centralize both rules and definitions (flags) in one or two
    | top level files which are included by all recursive makefiles.
    |
    | Recursive makefiles also have their advantages, particularly in large
    | projects where builds at the sub-directory level are useful.
    |
    | I disagree with the parallelism (-j4) concern, as properly designed makefiles
    | only have interdependecies higher in the tree, and elements at the same
    | level of the tree should be able to proceed in parallel, however it
    | is a simple matter to order targets that are dependent upon another
    | at the same level such they they can, where allowed, execute in parallel.
    |
    | If there are problems in mechanically generated makefiles (I assume you're
    | referring to those built by autoconf), then the generator (or the data
    | source (automake files)) need to be fixed, not the makefiles themselves.
    | This holds for imake as well as autoconf.

    This library I wrote has a custom "configure" script that builds one big flat
    Makefile for the whole thing.

    http://libh.slashusr.org/

    Once the Makefile is entirely flat, make can figure out all the dependencies
    and DTRT, and in parallel as best make possibly can (since it has the entire
    project in a single tree). FYI, make (at least the GNU version) has no hard
    coded limits on anything. Lines and strings can be as big as you want up to
    your available memory.

    --
    |WARNING: Due to extreme spam, I no longer see any articles originating from |
    | Google Groups. If you want your postings to be seen by more readers |
    | you will need to find a different place to post on Usenet. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

  10. Re: How to suppress 'Entering/Leaving ...' messages while running make?

    On Wed, 30 Apr 2008 21:40:34 +0000 (UTC), John Gordon wrote:
    >In scott@slp53.sl.home (Scott Lurndal) writes:
    >> Recursive makefiles also have their advantages, particularly in large
    >> projects where builds at the sub-directory level are useful.

    >
    > As the paper points out, a single Makefile is perfectly capable of doing
    > this. Just use "make subtarget" instead of "make".


    Yes, but at what cost? The subtargets have to be unique, and the
    proliferation of target names in a large multi-thousand source tree
    (like the FreeBSD src/ tree or the OpenSolaris source tree) is quickly
    going to get out of hand.

    The balance between overly complex target names and the time it takes to
    build a project using recursive makefiles is certainly not something as
    easy to 'resolve' as the paper seems to imply.


  11. Re: How to suppress 'Entering/Leaving ...' messages while runningmake?

    On May 1, 1:07 am, Giorgos Keramidas wrote:
    > On Wed, 30 Apr 2008 21:40:34 +0000 (UTC), John Gordon wrote:
    > >In sc...@slp53.sl.home (Scott Lurndal) writes:
    > >> Recursive makefiles also have their advantages, particularly
    > >> in large projects where builds at the sub-directory level are
    > >> useful.

    >
    > > As the paper points out, a single Makefile is perfectly capable
    > > of doing this. Just use "make subtarget" instead of "make".

    >
    > Yes, but at what cost? The subtargets have to be unique, and
    > the proliferation of target names in a large multi-thousand
    > source tree (like the FreeBSD src/ tree or the OpenSolaris
    > source tree) is quickly going to get out of hand.


    You don't define "get out of hand", so I'm not sure what precisely
    you're concerned about. Coming up with unique target names isn't hard
    because there's a prefix to use for these targets: the paths to the
    subdirectories. If that results in a conflict, then the existing,
    recursive make set up would already have that same conflict. (That's
    why, for example, the 'install' program is actually in the directory
    "usr.bin/xinstall" and built under the name "xinstall", or at least
    that's how the OpenBSD source tree avoids the conflict.)

    However, that's not particularly elegant. More elegant is to simply
    make the non-recursive setup behave similarly to the existing
    recursive setup when make is invoked in a subdirectory. When I
    converted a project (>80 directories total) from recursive to non-
    recursive make some time ago, I left a Makefile in each subdirectory
    such that simply typing "make" in a subdirectory would build the
    subset of the 'all' target that was notionally in or below that
    subdirectory. Those stub Makefiles only contained three lines: two
    assignments and an 'include' directive that pulled in the real 'top-
    level' Makefile, so it was still non-recursive and had the exact same
    knowledge (and effect) as a build from the top.

    In such a setup, running make in a subdir may build something
    'outside' that subdir if it's both out of date *and* a prerequisites
    for a target 'inside' the subdir, but that's the Right Thing.


    > The balance between overly complex target names and the time
    > it takes to build a project using recursive makefiles is certainly
    > not something as easy to 'resolve' as the paper seems to imply.


    Who cares how complex the target names are if you *never* have to type
    them? If the new setup supports the same 'make' usage patterns that
    the existing one does, then what's the issue?


    Philip Guenther

+ Reply to Thread