Issue 5568: make build output terse by default (issue 557080043 by nine.fierce.ballads@gmail.com)

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Issue 5568: make build output terse by default (issue 557080043 by nine.fierce.ballads@gmail.com)

nine.fierce.ballads
Reviewers: ,

Description:
https://sourceforge.net/p/testlilyissues/issues/5568/

The goal is to show progress without burying warnings and errors in
the noise of long commands.

Options VERBOSE=1 and SILENT=1 make the output more like the usual
"make" and "make -s" (respectively).

The verbosity level affects the options that are passed to some
commands, but there is room for improvement in this area.

Please review this at https://codereview.appspot.com/557080043/

Affected files (+231, -8 lines):
   M Documentation/GNUmakefile
   M Documentation/css/GNUmakefile
   M Documentation/logo/GNUmakefile
   M Documentation/ly-examples/GNUmakefile
   M Documentation/misc/GNUmakefile
   M Documentation/pictures/GNUmakefile
   M Documentation/po/GNUmakefile
   M Documentation/topdocs/GNUmakefile
   M GNUmakefile.in
   M elisp/GNUmakefile
   M input/regression/lilypond-book/GNUmakefile
   M input/regression/musicxml/GNUmakefile
   M lily/GNUmakefile
   M make/abc-rules.make
   M make/doc-i18n-root-rules.make
   M make/generic-rules.make
   M make/lilypond-book-rules.make
   M make/lilypond-book-vars.make
   M make/lilypond-vars.make
   M make/ly-rules.make
   M make/lysdoc-rules.make
   M make/midi-rules.make
   M make/musicxml-rules.make
   M make/mutopia-rules.make
   M make/stepmake.make
   M mf/GNUmakefile
   M stepmake/stepmake/c++-rules.make
   M stepmake/stepmake/c-rules.make
   M stepmake/stepmake/documentation-rules.make
   M stepmake/stepmake/executable-rules.make
   M stepmake/stepmake/generic-rules.make
   M stepmake/stepmake/help2man-rules.make
   M stepmake/stepmake/library-rules.make
   M stepmake/stepmake/metafont-rules.make
   M stepmake/stepmake/metafont-vars.make
   M stepmake/stepmake/python-module-rules.make
   M stepmake/stepmake/script-rules.make
   M stepmake/stepmake/shared-library-rules.make
   M stepmake/stepmake/substitute-rules.make
   M stepmake/stepmake/test-rules.make
   M stepmake/stepmake/tex-rules.make
   M stepmake/stepmake/texinfo-rules.make
   M stepmake/stepmake/texinfo-vars.make
   M vim/GNUmakefile



_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Issue 5568: make build output terse by default (issue 557080043 by nine.fierce.ballads@gmail.com)

Dev mailing list
Thanks for your efforts.  Some comments.

* What about using the automake format, for example

     CC     foo.o
     CCLD   bar
     FLEX   baz.c

   See the automake info manual, `Silencing Make', for more.

   In particular I think that the `Making ' string can be completely
omitted.

* I can imagine that it makes more sense to show paths (if at all)
relative to the top-level build or source directory.  This would allow a
quick comparison of compilation logs between two different
installations.

* The idea of showing the type of input file is nice; this might be a
useful addition to showing the processing program.  I'm not sure about
that, however.


https://codereview.appspot.com/557080043/

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Issue 5568: make build output terse by default (issue 557080043 by nine.fierce.ballads@gmail.com)

nine.fierce.ballads
In reply to this post by nine.fierce.ballads
On 2019/10/04 23:23:19, lemzwerg wrote:

> * I can imagine that it makes more sense to show paths (if at
> all) relative to the top-level build or source directory.  This
> would allow a quick comparison of compilation logs between two
> different installations.

It should be the build directory.  If you know how to achieve it
simply, I'll run a search and replace.  When I started, it wasn't
obvious how to achieve it, and then after I finished modifying
every rule everywhere, I lost interest in further research.


https://codereview.appspot.com/557080043/

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Issue 5568: make build output terse by default (issue 557080043 by nine.fierce.ballads@gmail.com)

Dev mailing list
In reply to this post by nine.fierce.ballads
> It should be the build directory.  If you know how to achieve it
> simply, I'll run a search and replace.

What about doing

   $(subst $configure-builddir,,$(abspath ...))

to strip off the builddir prefix?  This is untested, however


https://codereview.appspot.com/557080043/

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Issue 5568: make build output terse by default (issue 557080043 by nine.fierce.ballads@gmail.com)

nine.fierce.ballads
In reply to this post by nine.fierce.ballads
On 2019/10/04 23:23:19, lemzwerg wrote:
> * The idea of showing the type of input file is nice; this might be a
useful
> addition to showing the processing program.  I'm not sure about that,
however.

I wouldn't put up much of a fight if someone demanded removing
it, but I find it helpful, especially during the doc build, which
is not as familiar to me as "foo.o < cc".

Below is an example of where a person not thoroughly familar with
the build process might be helped by having the type of input
logged.  One could argue that at this point, someone wondering
what make is running could use VERBOSE=1, but it's still simpler
to find "< tex" than to work backward from the actual command to
its coded form in the makefile.

$(outdir)/%.tex:  %.lytex
        $(call ly_progress,Making,$@,< lytex)
        $(buildscript-dir)/run-and-check "$(LILYPOND_BOOK_COMMAND) --pdf -o
$(outdir) $<"  "$*.lytex.log"

$(outdir)/%.tex:  %.tex
        $(call ly_progress,Making,$@,< tex)
        $(LILYPOND_BOOK_COMMAND) --pdf -o $(outdir) $<
--
Dan


https://codereview.appspot.com/557080043/

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Issue 5568: make build output terse by default (issue 557080043 by nine.fierce.ballads@gmail.com)

Dev mailing list
In reply to this post by nine.fierce.ballads
We are getting nearer, thanks :-)

The next thing I notice is that `ly_progress` is (always?) called as

   $(call ly_progress,Making,$@,<comment>)

What about using `$$@` (or something like that to delay expansion) in
the definition of `ly_progress` and omitting `Making` as an argument,
too?  This would give

   $(call ly_progress,<comment>)

instead.

https://codereview.appspot.com/557080043/

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Issue 5568: make build output terse by default (issue 557080043 by nine.fierce.ballads@gmail.com)

nine.fierce.ballads
In reply to this post by nine.fierce.ballads
On 2019/10/05 13:44:54, lemzwerg wrote:
> We are getting nearer, thanks :-)

> What about using `$$@` (or something like that to delay expansion) in
the
> definition of `ly_progress` and omitting `Making` as an argument, too?
  This
> would give

>    $(call ly_progress,<comment>)

Too rigid.  You previously expressed a desire to see something like

     CC      foo.o

And that is not a bad idea, but is one that I view as less
valuable than other things I could work on.  To achieve that, the
process/tool needs to remain an argument of ly_progress.

There is also a question of whether it ever makes sense to
announce progress at intermediate points in a multi-command
recipe, and I think it might, even though I haven't done it
anywhere in this contribution.  To support that, the target needs
to remain an argument of ly_progress.

Also, there might be cases where $@ is not the most salient thing
to log in the progress message.  I'm thinking of cases like
timestamp files and phony targets.  There might be some of these
in the current contribution, but I did not want to spend time
polishing to that extent.


https://codereview.appspot.com/557080043/

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Issue 5568: make build output terse by default (issue 557080043 by nine.fierce.ballads@gmail.com)

Dev mailing list
In reply to this post by nine.fierce.ballads
> > What about using `$$@` (or something like that to delay expansion)
in
> > the definition of `ly_progress` and omitting `Making` as an
argument,
> > too?  This would give
> >
> >   $(call ly_progress,<comment>)

> Too rigid.  [...]

Ok.


https://codereview.appspot.com/557080043/

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel