Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: PATCH: Previous zsh.yo.in patch wasn't good enough



Bart Schaefer wrote:
>My thought (which I now see to have been half-formed) was that the docs
>were architecture-independent and hence the same for all builds

They are.  There used to be some configure-specific variable
interpolations, but they were all removed so that the documentation would
be the same everywhere.  This is a necessity, because we can't rely on the
availability of yodl to build a localised version of the documentation.
It is also useful in that people can refer to "page <X> of the Z Shell
Manual" and so on.

>of course it's possible to have two build trees with different name
>transforms.

Yes.  So far that's the only reason why we now need localised
documentation.

>This leads me to conclude that the $(tzsh).info change is either going
>too far, or not far enough:  If we're renaming zsh.info, why aren't we
>renaming zsh.1 and zshall.1 and zshbuiltins.1 etc?

Yes, we should.

>I *think* -- based on looking at automake-generated Makefile.in files --
>that program name transforms are intended strictly as an install-time
>thing, and should not affect compile-time file generation.  Its too bad
>that info format requires the files to reference their own names.

This suggests that we can do the variable replacement on the .texi file,
and then change the names only in the install.  We'd have the .yo files
generating zsh.texi.in in the source tree, and that gets distributed.
Then a sed over that generates zsh.texi in the build tree, with the
transformed name in the appropriate place.  We run makeinfo on that.
Then rename everything (executable, man pages, info files) as its being
installed.

We should probably also rename the lib directory, though this would
require additional effort to compile the transformed name into the
executable.  Same for the share directory.

-zefram



Messages sorted by: Reverse Date, Date, Thread, Author