groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] Tiny make patch: avoid Netpbm dependency


From: Steffen Nurpmeso
Subject: Re: [Groff] Tiny make patch: avoid Netpbm dependency
Date: Thu, 13 Mar 2014 12:52:10 +0100
User-agent: s-nail v14.6.2-9-gc4e43ca

Hello Ralph,

Ralph Corderoy <address@hidden> wrote:
 |Hi Steffen,
 |
 |>> It is a very good principle to put only real source files into a git
 |>> repository, and no generated files.  I will continue so.  My
 |>> successor might make a different decision, though.
 |> 
 |> Sure, that is your decision.
 |
 |It's also long-standing normal practice.  It's a real pain to look at
 |the differences between versions under *source* control and have them
 |cluttered with noisy differences between built outputs.

Ok, it is a fair point that the generated `configure' is truly
a real pain.  That would make me say several very subjective
things.

Using git(1) reduces diff noise a lot.  Just think about the
recent groffer removal / move / rename, or, on NetBSD, this night
the rumpkernel has seen file renames of the form
`xydir/component.c' -> `xydir/xy_component.c'.
Incredibly noisy in cvs(1).  With git(1) `diff' you can use
`-M' (`--find-renames') to cut the output to a summary line.

  address@hidden groff.git]$ gl1 fabbbb0
  commit fabbbb0e335801bc20f5c25fb0c448e23673721d
  Author: Bernd Warken <address@hidden>
  Date:   2014-02-25 16:59:42 +0100

      Rename mode pdf to pdf2 (using ps2pdf) and add new mode pdf (using groff
  ---
   contrib/groffer/ChangeLog         |   12 +
   contrib/groffer/Makefile.sub      |   74 +--
   contrib/groffer/README            |   19 +-
   contrib/groffer/README_PERL       |   51 ++
   contrib/groffer/func.pl           |  789 +++++++++++++++++++++++
   contrib/groffer/groffer.man       | 3946 ++++++++++++++++++++++++++++++++++
   contrib/groffer/groffer.pl        | 2225 ++++++++++++++++++++++++++++++++++
   contrib/groffer/man.pl            |  731 +++++++++++++++++++++
   contrib/groffer/perl/README_PERL  |  263 --------
   contrib/groffer/perl/func.pl      |  789 -----------------------
   contrib/groffer/perl/groffer.man  | 3920 ----------------------------------
   contrib/groffer/perl/groffer.pl   | 2209 ----------------------------------
   contrib/groffer/perl/man.pl       |  731 ---------------------
   contrib/groffer/perl/perl_test.pl |   34 -
   contrib/groffer/perl/roff2.pl     |  223 -------
   contrib/groffer/perl/split_env.sh |   48 --
   contrib/groffer/perl_test.pl      |   34 +
   contrib/groffer/roff2.pl          |  223 +++++++
   contrib/groffer/split_env.sh      |   48 ++
   contrib/groffer/version.sh        |    8 +-
   20 files changed, 8083 insertions(+), 8294 deletions(-)

  address@hidden groff.git]$ gl1 -M fabbbb0
  commit fabbbb0e335801bc20f5c25fb0c448e23673721d
  Author: Bernd Warken <address@hidden>
  Date:   2014-02-25 16:59:42 +0100

      Rename mode pdf to pdf2 (using ps2pdf) and add new mode pdf (using groff
  ---
   contrib/groffer/ChangeLog               |  12 +++++
   contrib/groffer/Makefile.sub            |  74 +++++++----------------------
   contrib/groffer/README                  |  19 ++------
   contrib/groffer/README_PERL             |  51 +++++++++++++++++++++
   contrib/groffer/{perl => }/func.pl      |   0
   contrib/groffer/{perl => }/groffer.man  |  46 ++++++++++++++-----
   contrib/groffer/{perl => }/groffer.pl   | 138 +++++++++++++++++++++++++++++
   contrib/groffer/{perl => }/man.pl       |   0
   contrib/groffer/perl/README_PERL        | 263 -----------------------------
   contrib/groffer/{perl => }/perl_test.pl |   0
   contrib/groffer/{perl => }/roff2.pl     |   0
   contrib/groffer/{perl => }/split_env.sh |   0
   contrib/groffer/version.sh              |   8 ++--
   13 files changed, 200 insertions(+), 411 deletions(-)

So this is an immense ease.
Then `configure' only needs to change when something changes, like
adding perl(1) detection or similar.

  address@hidden groff.git]$ git diff 1.21..1.22.2-real configure|wc -l
    2852

More than three years of a many-man show with autotools.
In comparison a year of a minimalistic homebrew one-and-a-half-man
configure written in plain sh(1) (couldn't resist)

  address@hidden nail.git]$ git diff heirloom..master mk-conf.sh |wc -l
    1381

The largest diff on `configure' arise from updated `autoconf'
versions, when looking at the complete history from 2002-07-21, the
release of Groff 1.18, until today.  Groff internal, i.e.,
configuration changes do not seem to cause any large impact on
`configure'.  Not that that changes anything.

A possible solution for easier proof-reading is to separate the
commits; this approach is taken by some operating systems when the
PCI database, for example, needs to be regenerated -- the first
commit covers the manual update of the templates, the second only
the automatic regeneration of the database.
If done like that, one can simply skip over such changesets.

The most subjective of all: currently checking out [master]
results in a system that is usable right away, all you need is GNU
make(1) and a plain UNIX / POSIX environment.  If `configure' is
dropped then you need a bunch of GNU tools that stack up to
hundreds of megabytes just for generating a shell script that in
itself is surprisingly stable for well more than a decade.  For me
this would mean to finally change Groff from a VCS repository to
a .tar_bomb_git one, because the repo as such is no longer usable.
Well, it is not so bad, i am not working with the sources, and am
not finding time for even the macros, and am subscribed to the
list, so that announcements will not get lost, but i'd feel less
"home" with one of the tools i really need.  Of course i could
have the git(1) repo plus a ball, or whatever.  In the end:
i always liked the idea: checked out working directory ==
distribution to go.  Now even with complete history.  Disconnect
from the net, turn off the light, light a candle, and linger
around a bit.

 |Cheers, Ralph.

Ciao,

--steffen



reply via email to

[Prev in Thread] Current Thread [Next in Thread]