groff
[Top][All Lists]
Advanced

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

Re: [Groff] new groff directory structure


From: Werner LEMBERG
Subject: Re: [Groff] new groff directory structure
Date: Mon, 30 Oct 2000 10:11:36 +0100 (CET)

[about versioned binaries similar to Emacs]

> > Maybe groff (the program) shall check how it is called.  If arg[0] is,
> > say, groff-1.16.1, it takes the `-1.16.1' postfix and appends it to
> > all programs it is calling, i.e., pic-1.16.1, grotty-1.16.1, etc.
> 
> I do NOT like the idea of groff checking how it is called. For one
> thing, it complicates groff for unnecessary reasons. Another is that
> one may wish to call different components of the groff package (eqn,
> tbl, pic, refer, troff, ... ) individually (as I often do). This
> suggested solution would have to be applied to each component, if
> they were respectively version-dependent also.

My idea was to let groff (the program) manage the versions.  In most
cases this would do a good job.  And no, only groff would have this
logic since none of the components calls other programs.

> Probably the smoothest way to arrange things is to have subtrees
> with version-dependent names (both in /usr/bin and /usr/...../groff
> etc), together with a rich set of symbolic links in the usual
> places.  However, this restructuring is pretty radical too ...

I can't see how this will solve the problem to avoid

  grn-1.16.1 xxx | pic-1.16.1 | ...

if the current version is, say, 1.17 -- or do you intend to add a
directory in front of $PATH pointing to your proposed `bin'
subdirectory?

Having subtrees in /usr/bin is, hmm, very strange.

Another solution (which is IMHO even better than my proposed changes
to groff): Install the pic binary as, say, pic-1.16.1 in the libexec
tree.  `pic' in /usr/local/bin then becomes a script which contains
something like

  : ${GROFF_VERSION-1.16.1}
  /usr/local/libexec/groff/$GROFF_VERSION/pic

If GROFF_VERSION isn't set, pic version 1.16.1 is called.  Otherwise,
the specified version will be used.

For MSDOS (and Windows?) it might be necessary to replace the scripts
with small binaries since batch files don't support pipes, AFAIK.

What about other packages with a couple of versioned binaries
(contrary to Emacs and gcc which basically only have a single binary)?


    Werner

reply via email to

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