Re: 4.3.90 release candidate

[Rik]

On 04/11/2018 10:09 AM, Mike Miller wrote:
> 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.
Fine.
>> 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.
So I can throw in a sed to strip things?

sed -e 's/^ \+//'

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

Agreed, this is not something I want to do now, but I was wondering if it
was possible.  It sounds like it *may* be possible.


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

Well, technically a user would only have to have a JRE installed rather
than a JDK installed.  That might be a nice thing.

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

Agreed, I'm not looking to re-architect the build system just before the
release.

--Rik