Re: Install munge-texi.pl for use by packages?

[Olaf Till]

On Mon, Jul 07, 2014 at 12:50:14PM -0400, Mike Miller wrote:
> On Mon, Jul 7, 2014 at 17:58:48 +0200, Olaf Till wrote:
> > On Mon, Jul 07, 2014 at 11:10:53AM -0400, Mike Miller wrote:
> >> On Sat, Jul 5, 2014 at 18:07:24 +0200, Olaf Till wrote:
> >> > Could munge-texi.pl be an installed component (maybe under a different
> >> > name) for use by packages for their documentation?
> >> >
> >> > Or would it be an additional hindrance for users building packages
> >> > with pkg() to assume the presence of Perl on systems like Windows?
> >>
> >> I would think that depending on Perl to install packages would be 
> >> undesirable.
> >>
> >> Or would you propose that the output of munge-texi.pl would be
> >> distributed in the package tarball so users installing the package do
> >> not need it? That only package maintainers (of packages that have
> >> Texinfo manuals) would need it to build the docs before uploading?
> >
> > I wouldn't propose the latter, since what is done by the package using
> > munge-texi.pl would completely be determined by the packages Makefile
> > and could only be done before tarball distribution by pre-compiling
> > the package.
> 
> That's not really a problem. As package maintainer, you can decide how
> much or how little to distribute in the tarball. As you know,
> Makefiles specify rules, if the file to be made already exists, make
> doesn't need to do anything.
> 
> Take a look at the communications package doc directory [1] for what I
> did to solve the exact problem you are looking at. Before tarring up
> the package to upload to sourceforge, I make the info documentation so
> it is part of the package distribution.
> 
> >> Alternatively, how complicated is munge-texi.pl? Could it be rewritten
> >> as an Octave function? I'm not looking at it at the moment.
> >
> > Probably, but only within a package or as an additional file, not as a
> > replacement for Octaves own file, since Octave uses it during the
> > build process :-).
> 
> That is not a problem at all, it could definitely replace Octave's
> existing script. Octave uses itself to build the images that go into
> the manual in the doc/interpreter directory, for example.

Oh, yes ... sorry.

> >> What does
> >> it do that you would like to use in your package?
> >
> > The same as what it does in an Octave build, incorporating function
> > help texts into the texinfo file.
> 
> Good, thanks for clarifying the actual goal, this is definitely
> something I agree with solving project-wide. And something that had
> been solved semi-package-wide in Octave Forge before the packages were
> split into separate repositories. There were perl scripts somewhat
> duplicating what Octave does to build its manual, in the admin
> directory of the svn repository IIRC. I copied those scripts into the
> communications hg repo to keep building the manual how it had been
> done before.
> 
> > The reason for my asking wasn't that rewriting munge-texi.pl in a
> > package would be too complicated, but that I thought there shouldn't
> > be two different versions of the same script, which might get out of
> > sync. It'd be just not "the right way". But I daresay it wouldn't be
> > impossible.
> 
> Yep, exactly as Carlo said, no reason for duplication, if we can
> replace this with an Octave script or function, it can also be used to
> build Octave's own manual as well.
> 
> I think these are great ideas, please file a wishlist bug on Octave to
> replace munge-texi.pl with an equivalent Octave function that can be
> used for both Octave's manual and for package manuals.

Ok, I'll do this, but I'll try to make the Octave function ready first
so you can possibly use it.

Olaf

> [1] https://hg.mtmxr.com/octave-communications/file/c74671b9a104/doc

-- 
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc
Description: Digital signature