groff
[Top][All Lists]
Advanced

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

quick and (not so) dirty applications of groff's build system (was: Grof


From: G. Branden Robinson
Subject: quick and (not so) dirty applications of groff's build system (was: Groff UTF-8 support? ...)
Date: Sat, 9 Mar 2024 12:40:41 -0600

Hi Dave,

At 2024-03-09T11:06:51-0600, Dave Kemper wrote:
> On 3/8/24, G. Branden Robinson <g.branden.robinson@gmail.com> wrote:
> > it didn't occur to me that people wouldn't just have make(1)
> > generate the real thing.
> 
> Well, you've found me out: I'm 99% ignorant of groff's build system.
> I periodically build the whole shebang, and don't touch it otherwise.
> I know it *can* build smaller parts, but I've never looked into the
> various targets.

The idiomatic name of a make(1) target is the name of a file you want
built.  For convenience (this is also something of a Unix tradition),
many of groff's build artifacts name their targets such that they're
built in the root of the build tree.[1]

So, if you need just the "troff" command (and whatever it depends on),
maybe for a quick experiment to test a change in
src/roff/troff/input.cpp you're not sure of, you can do this.

$ make -C build troff

Of, if you're building in the source tree like veteran of the Unix wars,
simply

$ make troff

I'm attaching Feldman's paper on make(1) from Seventh Edition Unix
(1979).  It's 10 pages long and you certainly don't need to read all of
it.  Despite some oddities (like those damned syntactically significant
tab characters), it's a terrific tool and is useful for far more than
compiling C programs.  Anywhere the nodes of a directed acyclic graph
are files, make(1) can likely be turned to the task.

> But more fundamentally, I was approaching the problem from a man-page
> mindset, where "see the rendered document" means "render it on the
> fly," not "render it to a file then look at that file."  So it didn't
> occur to me to look into turning one file into another, a problem that
> I may have looked to "make" to solve sooner.

I started out that way too, but quickly lost patience with all the
@SIGILS@.  I wanted to see the "real thing".

[...]
> Branden's advice to do a full git clone will make your life easier in
> the long run.  Then you can use "make" as intended to build the manual
> in a variety of formats.  One way that's better is that my
> cobbled-together solution doesn't scale well as more @KEYWORDS@ are
> added to groff.texi.in.

Just FYI, I have no plans or even notions for anything but @g@.

Regards,
Branden

[1] This includes all of the commands groff builds, from addftinfo to
    xtotroff, and the four static libraries.

Attachment: feldman.pdf
Description: feldman-make.pdf

Attachment: signature.asc
Description: PGP signature


reply via email to

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