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

[Mike Miller]

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.

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

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

-- 
mike