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

[Steffen Nurpmeso]

Hello,

Werner LEMBERG <address@hidden> wrote:
 |> for me the dependency upon Netpbm is "annoying"; i always restart
 |> failed makes to get over all related problems: like that
 |> (single-threaded) compilation is just fine.
 |
 |With the distributed tarballs, there is *no* dependency on Netpbm!

This may be so, i've indeed never (iirc) tried to use a release
ball, and was only looking into the FTP dir to be able to compare
against the actual file size...
Sorry that i haven't made that very clear: i was referring to
a git(1) checkout working directory.

 |> Configuration checks for (some) Netpbm programs and avoids
 |> $make_html as necessary -- however, xpmtoppm(1), pnmdepth(1) and
 |> pnmtops(1) are still required to generate `gnu.eps', which in turn
 |> is used by some examples only; etc.
 |
 |`gnu.eps' *is* distributed in the groff-1.22.2 tarball, in the `dir'
 |subdirectory.  How do you get the impression that it is missing?

Never looked into such a ball, sorry (again).

 |Looking into the archive, I see that `gnu.eps's timestamp is 10
 |seconds after the one of `gnu.xpm'; this means that the dependencies
 |are correctly fullfilled, and a call to `make' doesn't try to
 |regenerate the EPS file.
 |
 |If you do a normal `./configure && make && make install' incantation,
 |and you experience problems with `gnu.eps', please show a log file of
 |the build process.

So no, i definetely can't do *that* -- it seems it is just
charming when done in a release tarball.

...and no chance to take advantage of git(1) compressing it's
blobs, which is what i was indeed referring to?  The bitmap seems
to be unchanged from the first check-in until today (and i can't
imagine that someone wants to change that one, too).
It is maybe worth thinking about doing so for GNU Troff, as it is
the only step that is missing to have `VCS-checkout ==
distribution-to-go', which seems to me is a desirable thing; it
anyway lowers the hurdle of using Groff, a pretty current one for
sure.

It seems more and more projects do not even provide release balls,
but require packagers to do that work for them; e.g., the Netpbm
version that is required to get the PNG related tools (those which
actually work with PNG library versions >v1.4) isn't shipped by
the author as a ball no more at all, you need to have subversion
installed and export a state, as in, e.g.,

  $ svn export http://svn.code.sf.net/p/netpbm/code/release_number/10.64.06

Unfortunately Sourceforge itself doesn't even offer a way to get
a ball of such a directory at all!  Only the HEAD!  Sic!!
But besides the need for subversion the approach as such i like.
E.g., if i would be a MOM user i surely would have loved to get
the new thing at a glance, and for Groff it would have worked like
that.  (Having multiple branches to decide what is stable and what
not is the usual approach, and i guess in such a situation the MOM
update, that matured somewhere else (what me thinks), could have
been pushed to [master] immediately, whereas other changes may
still reside on [next] or wherever else.)

 |    Werner

--steffen