Hello, Werner LEMBERG <w...@gnu.org> 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
