Re: 4.3.90 release candidate

[Mike Miller]

On Wed, Apr 11, 2018 at 09:40:10 -0700, Rik wrote:
> 1) gnu+11 variant rather than straight C++11 dialect chosen by configure. 
> I don't think we are taking advantage of any gnu++11 extensions so it
> shouldn't be a problem on machines with g++.

This is intentional.

> 2) Extra space for FLTK variables in summary at end of configure
[…]
> Not an issue, but why is it different from everything else?

Probably because everything else uses pkg-config, and FLTK uses
fltk-config. The extra space is inside the variables.

> 5) Generated language files which are probably static
[…]
> We ship the fully generated forms of the documentation so that users don't
> have to have a full TeXinfo system installed.  Should we also be shipping
> the compiled versions of the language files for Qt?  Maybe they did change
> the internal binary representation between Qt4 and Qt5 so we can't
> construct these until compile time.  But if this is not the case, then I
> think it would be useful to distribute these files so users don't need to
> install more tools around foreign language translation.

We already require all of the Qt tools, including lrelease, when
building with Qt. If configure already requires them to have the tools,
then they might as well build them.

Maybe worth looking into for the next release.

> 6) Java class files are generated, rather than shipped in the tarball.
[…]
> Same for jar file
[…]
> Isn't it the case that a compiled java file is just byte code that can be
> read and run anywhere?  If that is correct then we could make these files
> and just distribute them in the tarball.  However, if these really are part
> of the JNI interface to C++ then maybe they do have to be generated on the
> host computer at the same time Octave is built.

This is intentional. We used to include octave.jar in the source
distribution. But when a user builds Octave 4.2.2, for example, make
detects that the .class files are missing, recompiles them, and then
rebuilds octave.jar anyway.

So the de facto state has always been that the user was compiling the
Java code on their own computer anyway, why fight it?

Aside: the octave.jar file is a zip file that contains embedded
timestamps, and I am trying to make the source distribution more
reproducible.

For the next release we could look at including the Java bytecode and
jar file in the source distribution, but please don't make that change
now.

-- 
mike

signature.asc
Description: PGP signature