[OctDev] Re: email not getting through

[Paul K. <pki...@us...>]

On Jun 2, 2004, at 7:58 AM, David Bateman wrote:

> According to Paul Kienzle <pki...@us...> (on 
> 06/02/04):
>>
>> Does building octave-forge from a release version require perl?
>> Certainly generating new octave-forge releases requires perl
>> and other tools.
>
> The comms and fixed stuff use a script mktexi and mkdoc which are in
> perl to create the texinfo documentation, in a process similar to that
> in octave itself (except there it is don't with c++ code). These 
> packages
> also use the texinfo package to build the docs, which I chosen also to
> be compatiable with octave itself.
>
> If I'm required to get rid of these dependencies, then ok. But a good
> means of producing documentation that is
>
> 1) available from with octave, and
> 2) can be built into postscript, pdf and html
>
> must be defined, that is preferable common to all packages.
>
>> I suppose so long as the output files needed for installation
>> can be created by hand reasonably if the author doesn't
>> want to install python, then the use of python as an aid is
>> acceptable. Again, it is not acceptable requirement for an
>> end-user system.
>
> so what do you think of perl and texinfo :-)

texinfo is not a problem since a correct octave installation will
have already required it if necessary (or not, in which case the
doc is a little uglier).

John is very good about pre-building targets that depend on
flex, bison and perl, etc., before he makes a new octave release.
That way users don't need these tools on their systems unless
they want to modify the parts of octave that require them.  We
ought to be doing so as well if we are not already.

So in an idealized packaging environment, if authors want to
create compliant packages, they should be able to fill in all the
bits by hand, but we can provide tools to automate the process
if they are willing to install more stuff on their system.  Does that
sound right?

- Paul