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

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Dec 5, 12:34pm, Zefram wrote:
} Subject: Re: PATCH: Previous zsh.yo.in patch wasn't good enough
}
} Bart Schaefer wrote:
} >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'm actually beginning to think we *shouldn't*, not even for the info.

} >[...] 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.

If the only line that needs to change is the @setfilename line, then this
might be possible.

} 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.

The easiest way to do this is to get rid of the "%.info: $(tzsh).texi"
rule and simply have "install.info: $(sdir)/zsh.texi.in".  Otherwise we
have to generate the transformed program name for purposes of determining
the make targets and dependencies, which is painful (as Clint's trick of
calling "make -f - <<EOF" from configure has demonstrated).

} 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.

Ick.  This is enough to make me want to back off the name transformations
entirely.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com