[Top][All Lists]

[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: Wed, 12 Mar 2014 14:49:42 +0100
User-agent: s-nail v14.6.2-9-gc4e43ca

Werner LEMBERG <address@hidden> wrote:
 |> ...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 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 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;
 |No, it isn't, IMHO.  For example, many people don't have `makeinfo'

Yes.. but i mostly hang around with operating systems (e.g.
NetBSD, ArchLinux) which ship those info tools, including
makeinfo(1), by default.

 |installed to build the info files, or `autoconf' to generate the
 |configure script.  People who check out from the git *must* have all

Hah!  I was really thankful that the generated `configure' became
part of the git(1) repo -- *thank you* for this decision!

I will not start a rant on one of the most horrifying pieces of
software ever written (GNU autotools), because i see that even
a complicated piece of software like GNU Troff can be driven with
a 128KB m4/ directory.

 |the necessary tools.  In case you really can't manage to install the
 |netpbm tools (something which I rather doubt), it's still possible to

Yes i did, yesterday -- it was the shown `export' plus a configure
run (i used static linking to avoid any possible problems with
Apple .dylib, though).
One `FALSE' assignment must be changed to a `NULL' one, that's all.
(That is: you need to be a programmer.)

 |  touch gnu.eps

Would it make sense to send a patch that does this if at the end
of all the conditions there is still no `gnu.eps'?
With the pre-shipped `configure' and a distribution-provided
makeinfo(1) that is what is missing for distribution-to-go, like
i've said.  But of course it doesn't sound like you love that.

 |to get an empty file and the build process should finish successfully.

Yes, one can get through it.

 |> It seems more and more projects do not even provide release balls,
 |> but require packagers to do that work for them; [...]
 |I very much dislike this idea.  Fortunately, since groff is a GNU
 |project, we don't go this route.
 |> E.g., if i would be a MOM user i surely would have loved to get
 |> the new thing at a glance,
 |You can do so, since Peter distributes MOM separately, exactly for
 |this reason.

Yes, i didn't know that but obviously he does.

Well, i long have the plan to unrot our *roff macros and (that is
the plan) add all the functionality of our beloved but lost TeX
package into it, so as to make it a real package, for users.  It
would be nice if at that time Groff would consider it for
inclusion, just like it did with MOM, but that'll be a long road.

Thank you and ciao

 |    Werner


reply via email to

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