Re: help broken in 3.8.0 ? Missing macros.texi

[JFC]

On 1/1/14 8:45 PM, Mike Miller wrote:
> On Tue, 31 Dec 2013 17:18:47 +0100, JFC wrote:
> > On 12/31/13 3:51 PM, JFC wrote:
> > > Also, in my previous (3.6.2) build, I was passing --disable-docs
> > > but was still able to get help at the octave prompt.
> > >
> > > Finally, it is sufficient in 3.8.0 to move the macros.texi file
> > > to the right place in the install directory to get back
> > > the help functionality even when building with --disable-docs
> > > so I do not see the benefit of not installing macros.texi.
> > >
> > > Last point: I redid a ./configure without --disable-docs
> > > and I do not see a change to octetc_DATA in the Makefile.
> > > I will rebuild with that and, if successful, will report.
> >
> >
> > OK, you were right: building without --disable-docs fixes
> > the online help system.  Note for OSX users: on OSX 10.6.8, at least,
> > one has to override the system's texi2dvi in /usr/bin
> > by the one found, for instance, here:
> > http://ftp.gnu.org/gnu/texinfo/texi2dvi
> >
> > Maybe there is room for improvement here if it is sufficient
> > to install a macros.texi file in the right place to have
> > help functionality without having to build the whole doc set.


> The released tarballs should have documentation already built and
> provided with the source. You shouldn't need to pass --disable-docs to
> configure and make should not have to do anything when it recurses into
> the doc directories. If you find that you do need texi2dvi to build the
> 3.8.0 source release, this might be a bug.

I can confirm that if I build without --disable-docs, texi2dvi is
invoked during the build.

But, again, don't we have a problem here?  When I say that
interactive help is broken when building with --disable-docs,
I do not refer to reading the manual at the octave prompt,
but just to invoking: $ help <function_name>

Is that help really supposed to be suppressed when building with
--disable-docs ?  It was not the case with 3.6.2, for instance.
If it is not the case for 3.8.0, then we have a regression, don't we?

Actually it is not the build of 3.8.0 which seems broken to me when
using --disable-docs, **but the install** after the build.
Indeed, help works when octave is run after the build as ./run-octave


Consider this :

1) a new file macros.texi as well as a new function texi_macros_file ()
   have recently (at least since 3.6.2) been introduced in octave.

2) the file does exist in the tarball as 
octave-3.8.0/doc/interpreter/macros.texi
   and should be installed at the location pointed by the texi_macros_file ()
   function, which by default is <installdir>/share/octave/3.8.0/etc/macros.texi
   If it is not there, the interactive help craps out.

My understanding is that the install has not been properly updated to
take care of the recently introduced macros.texi file when the switch
--disable-docs is passed to configure.

But of course, I would be wrong if --disable-docs is supposed
(regressively) to suppress interactive help.

> There is a lot of overlap between the help text that is generated
> for the interactive help and for the manual, so there is probably
> not much interest in separating the logic for the two.

I see.

> Also because users get the documentation prebuilt with the source so
> they should not need the tools and they should not need
> --disable-doc.

But if all the doc is prebuilt, a user does not need the tools for
building it and thus can benefit from the --disable-docs switch.
Unless using it breaks the help, of course...

I thought that --disable-docs was intended at least to avoid the
dependency on a latex system (and possibly other tools).

Best, JF