Re: 4.3.90 release candidate

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: 4.3.90 release candidate

Rik-4
I just compiled on a vanilla Linux machine (Mint 18.1 based on Ubuntu 16.04).

I get no failures when running 'make check' so that is good.

Summary:

  PASS                            14853
  FAIL                                0
  XFAIL (reported bug)               31
  XFAIL (expected failure)            5
  SKIP (missing feature)            138
  SKIP (run-time condition)          12


I did notice the following things:

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

 C++ compiler:                  g++ -std=gnu++11  -pthread -fopenmp  -Wall
-W -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align
-Wcast-qual -O2 -pipe
 
2) Extra space for FLTK variables in summary at end of configure

  FFTW3F libraries:              -lfftw3f_threads -lfftw3f
  FLTK CPPFLAGS:                  -I/usr/include/cairo
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
-I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12
-I/usr/include/freetype2
  FLTK LDFLAGS:                   -Wl,-Bsymbolic-functions
  FLTK libraries:                 -lfltk_gl -lfltk -lX11
  fontconfig CPPFLAGS:           -I/usr/include/freetype2

Not an issue, but why is it different from everything else?

3) Release Notes do not have date filled in.

Summary of important user-visible changes for version 4.4 (yyyy-mm-dd):

Maybe this is filled in only when the actual release is made, in which case
this is fine for the present.

4) README file sizes are incorrect

Octave requires approximately 1.4 GB of disk storage to unpack and
compile from source (significantly less, 400 MB, if you don't compile
with debugging symbols).  Once installed, Octave requires
approximately 350 MB of disk space (again, considerably less, 70 MB,
if you don't build shared libraries or the binaries and libraries do
not include debugging symbols).

For my build it was 468 MB and 73 MB without debugging.  I will rebuild
with debugging symbols and update the README file with correct values.

5) Generated language files which are probably static

  GEN      libgui/default-qt-settings
  GEN      libgui/languages/be_BY.qm
  GEN      libgui/languages/ca_ES.qm
  GEN      libgui/languages/de_DE.qm
  GEN      libgui/languages/en_US.qm
  GEN      libgui/languages/es_ES.qm
  GEN      libgui/languages/eu_ES.qm
  GEN      libgui/languages/fr_FR.qm
  GEN      libgui/languages/it_IT.qm
  GEN      libgui/languages/ja_JP.qm
  GEN      libgui/languages/nl_NL.qm
  GEN      libgui/languages/pt_BR.qm
  GEN      libgui/languages/pt_PT.qm
  GEN      libgui/languages/ru_RU.qm
  GEN      libgui/languages/uk_UA.qm
  GEN      libgui/languages/zh_CN.qm

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.

6) Java class files are generated, rather than shipped in the tarball.

  GEN      scripts/java/org/octave/ClassHelper.class
  GEN      scripts/java/org/octave/Matrix.class
  GEN      scripts/java/org/octave/OctClassLoader.class
  GEN      scripts/java/org/octave/Octave.class
  GEN      scripts/java/org/octave/OctaveReference.class

Same for jar file

  GEN      scripts/java/octave.jar

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.

7) Java warnings during build

Note: org/octave/ClassHelper.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

There is already a bug report about this
(https://savannah.gnu.org/bugs/?53550).  I think newbie users are going to
be freaked out by this message, even though it appears to cause no trouble
at all.

--Rik

Reply | Threaded
Open this post in threaded view
|

Re: 4.3.90 release candidate

Avinoam
Rik-4 wrote

> I just compiled on a vanilla Linux machine (Mint 18.1 based on Ubuntu
> 16.04).
>
> I get no failures when running 'make check' so that is good.
>
> Summary:
>
>   PASS                            14853
>   FAIL                                0
>   XFAIL (reported bug)               31
>   XFAIL (expected failure)            5
>   SKIP (missing feature)            138
>   SKIP (run-time condition)          12
>
>
> I did notice the following things:
>
> 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++.
>
>  C++ compiler:                  g++ -std=gnu++11  -pthread -fopenmp  -Wall
> -W -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align
> -Wcast-qual -O2 -pipe
>  
> 2) Extra space for FLTK variables in summary at end of configure
>
>   FFTW3F libraries:              -lfftw3f_threads -lfftw3f
>   FLTK CPPFLAGS:                  -I/usr/include/cairo
> -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
> -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12
> -I/usr/include/freetype2
>   FLTK LDFLAGS:                   -Wl,-Bsymbolic-functions
>   FLTK libraries:                 -lfltk_gl -lfltk -lX11
>   fontconfig CPPFLAGS:           -I/usr/include/freetype2
>
> Not an issue, but why is it different from everything else?
>
> 3) Release Notes do not have date filled in.
>
> Summary of important user-visible changes for version 4.4 (yyyy-mm-dd):
>
> Maybe this is filled in only when the actual release is made, in which
> case
> this is fine for the present.
>
> 4) README file sizes are incorrect
>
> Octave requires approximately 1.4 GB of disk storage to unpack and
> compile from source (significantly less, 400 MB, if you don't compile
> with debugging symbols).  Once installed, Octave requires
> approximately 350 MB of disk space (again, considerably less, 70 MB,
> if you don't build shared libraries or the binaries and libraries do
> not include debugging symbols).
>
> For my build it was 468 MB and 73 MB without debugging.  I will rebuild
> with debugging symbols and update the README file with correct values.
>
> 5) Generated language files which are probably static
>
>   GEN      libgui/default-qt-settings
>   GEN      libgui/languages/be_BY.qm
>   GEN      libgui/languages/ca_ES.qm
>   GEN      libgui/languages/de_DE.qm
>   GEN      libgui/languages/en_US.qm
>   GEN      libgui/languages/es_ES.qm
>   GEN      libgui/languages/eu_ES.qm
>   GEN      libgui/languages/fr_FR.qm
>   GEN      libgui/languages/it_IT.qm
>   GEN      libgui/languages/ja_JP.qm
>   GEN      libgui/languages/nl_NL.qm
>   GEN      libgui/languages/pt_BR.qm
>   GEN      libgui/languages/pt_PT.qm
>   GEN      libgui/languages/ru_RU.qm
>   GEN      libgui/languages/uk_UA.qm
>   GEN      libgui/languages/zh_CN.qm
>
> 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.
>
> 6) Java class files are generated, rather than shipped in the tarball.
>
>   GEN      scripts/java/org/octave/ClassHelper.class
>   GEN      scripts/java/org/octave/Matrix.class
>   GEN      scripts/java/org/octave/OctClassLoader.class
>   GEN      scripts/java/org/octave/Octave.class
>   GEN      scripts/java/org/octave/OctaveReference.class
>
> Same for jar file
>
>   GEN      scripts/java/octave.jar
>
> 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.
>
> 7) Java warnings during build
>
> Note: org/octave/ClassHelper.java uses unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
>
> There is already a bug report about this
> (https://savannah.gnu.org/bugs/?53550).  I think newbie users are going to
> be freaked out by this message, even though it appears to cause no trouble
> at all.
>
> --Rik


Any plans to create  windows installer for 4.3.90 release candidate?

Avinoam



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: 4.3.90 release candidate

Mike Miller-4
In reply to this post by Rik-4
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 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 4.3.90 release candidate

Rik-4
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

Reply | Threaded
Open this post in threaded view
|

Re: 4.3.90 release candidate

Mike Miller-4
On Wed, Apr 11, 2018 at 10:27:05 -0700, Rik wrote:
> On 04/11/2018 10:09 AM, Mike Miller wrote:
> > 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/^ \+//'

Oh, I remember now, we have a loop over all the words returned by
fltk-config --cflags and --ldflags, because we only want options that
start with -I and -l. So the extra space is the typical result of doing

    FLTK_CPPFLAGS="$FLTK_CPPFLAGS $fltk_option"

in a loop, where FLTK_CPPFLAGS starts out empty. So you could fix that
with something like

    FLTK_CPPFLAGS="${FLTK_CPPFLAGS:+$FLTK_CPPFLAGS }$fltk_option"

Or just use sed at the end.

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

Yes we could identify which Qt tools are needed to build the release
(lrelease, qcollectiongenerator), and which are needed to build code,
and separate that logic in configure to make certain tools optional,
maybe with the build-aux/missing helper script.

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

The end user still needs the jni.h header file to compile ov-java.cc,
which is part of the JDK.

For mxe-octave we pull jni.h from the web, we could possibly include
some known version of jni.h in the source tree for all platforms.

--
mike

signature.asc (849 bytes) Download Attachment