SciDAVis 2.9 release #24

highperformancecoder · 2022-04-16T07:42:57Z

No description provided.

Update obsCheck for Leap distros

linguist is not installed

This reverts commit b1529c9.

lupdate clobbering the translations.

alxpl · 2022-04-16T15:46:25Z

Hello Russel,

That's quite a lot of work there!
I found a few issues with some paths and had to patch a couple of lines here and there to get everything working on current Fedora branches.
I'm preparing for a PhD defense in a few days, so I did not have the time to examine things in depth and I did not dare update SciDAVis on my computers, while I'm still reworking some of my plots.

What needed patching:

In CMakeLists.txt, I moved the GNUInstallDirs include statement right after the project declaration.

diff -Naur a/CMakeLists.txt b/CMakeLists.txt
--- a/CMakeLists.txt	2022-04-16 11:37:37.000000000 +0200
+++ b/CMakeLists.txt	2022-04-16 16:14:37.723316431 +0200
@@ -1,5 +1,4 @@
 cmake_minimum_required( VERSION 3.16 )
-include(GNUInstallDirs)
 
 # Target platform is Windows 10
 if( CMAKE_GENERATOR STREQUAL "Visual Studio 15 2017" OR
@@ -14,6 +13,7 @@
   DESCRIPTION "SciDAVis is a free application for Scientific Data Analysis and Visualization."
   HOMEPAGE_URL "https://scidavis.sourceforge.net"
   LANGUAGES CXX C)
+include(GNUInstallDirs)
 
 set( CMAKE_CXX_STANDARD 17)
 set( CMAKE_CXX_STANDARD_REQUIRED TRUE )

CMake at least since version 3.17 expects it to be there, otherwise any path that depends on it is never set. I remember seeing the relevant error message when compiling previous versions, but it never registered, sorry…

I also had to revert the change in the qwtplot3d name in 3rdparty/CMakeLists.txt:

diff -Naur a/3rdparty/CMakeLists.txt b/3rdparty/CMakeLists.txt
--- a/3rdparty/CMakeLists.txt	2022-04-16 11:37:37.000000000 +0200
+++ b/3rdparty/CMakeLists.txt	2022-04-16 14:14:11.667153679 +0200
@@ -47,7 +47,7 @@
 
 if( NOT BUILD_QWTPLOT3D )
 find_library ( QWTPLOT3D_LIBRARY
-    NAMES qwtplot3d
+    NAMES qwtplot3d-qt5
     HINTS ${QT_LIBRARY_DIR}
   )
   if( NOT QWTPLOT3D_LIBRARY )

With GNUInstallDirs now taken into account, I had to modify the following path variables in libscidavis/CMakeLists.txt:

diff -Naur a/libscidavis/CMakeLists.txt b/libscidavis/CMakeLists.txt
--- a/libscidavis/CMakeLists.txt	2022-04-16 11:37:37.000000000 +0200
+++ b/libscidavis/CMakeLists.txt	2022-04-16 15:54:37.363785188 +0200
@@ -409,9 +409,9 @@
     )
 else()
   target_compile_definitions( libscidavis PUBLIC
-    TS_PATH="${CMAKE_INSTALL_PREFIX}/share/scidavis/translations"
-    DOC_PATH="${CMAKE_INSTALL_PREFIX}/share/doc/scidavis"
-    PLUGIN_PATH="${CMAKE_INSTALL_PREFIX}/lib/scidavis/plugins"
+    TS_PATH="${CMAKE_INSTALL_DATAROOTDIR}/scidavis/translations"
+    DOC_PATH="${CMAKE_INSTALL_DOCDIR}/scidavis"
+    PLUGIN_PATH="${CMAKE_INSTALL_LIBDIR}/scidavis/plugins"
     )
 endif()

A couple of questions:
In scidavis/CMakeLists.txt, there's this conditional:

    if( SCRIPTING_PYTHON )
      if(NOT PYTHON_SCRIPTDIR)
        set(PYTHON_SCRIPTDIR etc)
      endif()

Why does it begin with a NOT? Was PYTHON_SCRIPTDIR supposed to be declared someplace else? I don't see a setting in ~/.config/SciDAVis.conf for example.
Why set the path to /etc/? Is there any fairly recent distribution that keeps Python scripts there?

highperformancecoder · 2022-04-16T23:08:59Z

Hello Russel,

That's quite a lot of work there!

I guess I haven't merged up in a while. It's just such an ornery piece of code, that I'd run out of time before solving the problems, so merge up go forgotten about.

I found a few issues with some paths and had to patch a couple of lines here and there to get everything working on current Fedora branches. I'm preparing for a PhD defense in a few days, so I did not have the time to examine things in depth and I did not dare update SciDAVis on my computers, while I'm still reworking some of my plots.

Make sense. When I was doing my PhD, we'd have 18 month upgrade cycle, so that you could rely on your software working for at least half a PhD. But today, we seem to have weekly upgrades :P

What needed patching:

In CMakeLists.txt, I moved the GNUInstallDirs include statement right after the project declaration.
diff -Naur a/CMakeLists.txt b/CMakeLists.txt
--- a/CMakeLists.txt	2022-04-16 11:37:37.000000000 +0200
+++ b/CMakeLists.txt	2022-04-16 16:14:37.723316431 +0200
@@ -1,5 +1,4 @@
 cmake_minimum_required( VERSION 3.16 )
-include(GNUInstallDirs)
 
 # Target platform is Windows 10
 if( CMAKE_GENERATOR STREQUAL "Visual Studio 15 2017" OR
@@ -14,6 +13,7 @@
   DESCRIPTION "SciDAVis is a free application for Scientific Data Analysis and Visualization."
   HOMEPAGE_URL "https://scidavis.sourceforge.net"
   LANGUAGES CXX C)
+include(GNUInstallDirs)
 
 set( CMAKE_CXX_STANDARD 17)
 set( CMAKE_CXX_STANDARD_REQUIRED TRUE )
CMake at least since version 3.17 expects it to be there, otherwise any path that depends on it is never set. I remember seeing the relevant error message when compiling previous versions, but it never registered, sorry…

I also had to revert the change in the qwtplot3d name in 3rdparty/CMakeLists.txt:
diff -Naur a/3rdparty/CMakeLists.txt b/3rdparty/CMakeLists.txt
--- a/3rdparty/CMakeLists.txt	2022-04-16 11:37:37.000000000 +0200
+++ b/3rdparty/CMakeLists.txt	2022-04-16 14:14:11.667153679 +0200
@@ -47,7 +47,7 @@
 
 if( NOT BUILD_QWTPLOT3D )
 find_library ( QWTPLOT3D_LIBRARY
-    NAMES qwtplot3d
+    NAMES qwtplot3d-qt5

This was Andrew Ammerlaan's change:

" 3rdparty/CMakeLists.txt: find qwtplot3d

- qwtplot3d is the default name of the library so lets us that in favour of
 qwtplot3d-qt5

Signed-off-by: Andrew Ammerlaan <andrewammerlaan@gentoo.org>

If you use the submodules (as I do), there is no problem with either setting.

 HINTS ${QT_LIBRARY_DIR}
)
if( NOT QWTPLOT3D_LIBRARY )
With GNUInstallDirs now taken into account, I had to modify the following path variables in libscidavis/CMakeLists.txt:
diff -Naur a/libscidavis/CMakeLists.txt b/libscidavis/CMakeLists.txt
--- a/libscidavis/CMakeLists.txt 2022-04-16 11:37:37.000000000 +0200
+++ b/libscidavis/CMakeLists.txt 2022-04-16 15:54:37.363785188 +0200
@@ -409,9 +409,9 @@
)
else()
target_compile_definitions( libscidavis PUBLIC

TS_PATH="${CMAKE_INSTALL_PREFIX}/share/scidavis/translations"

DOC_PATH="${CMAKE_INSTALL_PREFIX}/share/doc/scidavis"

PLUGIN_PATH="${CMAKE_INSTALL_PREFIX}/lib/scidavis/plugins"

TS_PATH="${CMAKE_INSTALL_DATAROOTDIR}/scidavis/translations"

DOC_PATH="${CMAKE_INSTALL_DOCDIR}/scidavis"

PLUGIN_PATH="${CMAKE_INSTALL_LIBDIR}/scidavis/plugins"
)
endif()
A couple of questions: In scidavis/CMakeLists.txt, there's this conditional:
if( SCRIPTING_PYTHON )
  if(NOT PYTHON_SCRIPTDIR)
    set(PYTHON_SCRIPTDIR etc)
  endif()
Why does it begin with a NOT? Was PYTHON_SCRIPTDIR supposed to be declared someplace else? I don't see a setting in ~/.config/SciDAVis.conf for example. Why set the path to /etc/? Is there any fairly recent distribution that keeps Python scripts there?

Again this is Andrew Amerlaan's change: His commit log says:

CMakeLists.txt: several fixes

- share/appdata is deprecated in favour of share/metainfo
- use CMAKE_INSTALL_DOCDIR from GNUInstallDirs for docs
- only look for muparser if we have it enabled
    (TODO: fix building with muparser disabled)
- add PYTHON_SCRIPTDIR that can be overriden to change the location
    of the python files.
    (TODO: change the default, /usr/etc is a very strange path)

So it sounds like he is not fixed on the value etc.

This reverts commit 73438b5.

Nowa-Ammerlaan · 2022-04-21T17:36:53Z

Why does it begin with a NOT? Was PYTHON_SCRIPTDIR supposed to be declared someplace else? I don't see a setting in ~/.config/SciDAVis.conf for example. Why set the path to /etc/? Is there any fairly recent distribution that keeps Python scripts there?

Again this is Andrew Amerlaan's change: His commit log says:

CMakeLists.txt: several fixes

- share/appdata is deprecated in favour of share/metainfo
- use CMAKE_INSTALL_DOCDIR from GNUInstallDirs for docs
- only look for muparser if we have it enabled
    (TODO: fix building with muparser disabled)
- add PYTHON_SCRIPTDIR that can be overriden to change the location
    of the python files.
    (TODO: change the default, /usr/etc is a very strange path)

So it sounds like he is not fixed on the value etc.

The NOT is there to allow overriding the strange etc path without changing the default behaviour: 2597372 Previously the python files were installed into etc without anyway to override this strange path. But yes the default should really be changed, etc is not meant for python scripts. I did not change it in my earlier commit because I was unsure what would be a proper cross-distro default setting for this, in Gentoo we keep them in /usr/lib/python-exec/pythonX.Y but I don't know what other distro's are doing.

narunlifescience

I am not very good at reviewing scripts & cmake files. looks good to me anyway.

alxpl · 2022-05-08T13:51:31Z

[…] But yes the default should really be changed, etc is not meant for python scripts. I did not change it in my earlier commit because I was unsure what would be a proper cross-distro default setting for this, in Gentoo we keep them in /usr/lib/python-exec/pythonX.Y but I don't know what other distro's are doing.

In Fedora (and the rest of the family) we've been using a macro (%{python3_sitearch}), which on my F35 x86_64 system evaluates to:
/usr/lib64/python3.10/site-packages
so the full installation path is
/usr/lib64/python3.10/site-packages/scidavis

At least OpenSUSE and friends also use separate paths for 32- and 64-bit.

See https://docs.python.org/3/library/sys.html#sys.platlibdir

alxpl · 2022-05-08T13:55:12Z

Now that I have time to spare again, I 've been using this code base for the last couple of days and I haven't hit any regressions, so I am going to merge, considering there are some fixes which are required downstream.

highperformancecoder · 2022-05-08T22:46:34Z

Thanks Alex. Actually, there is one major regression which affects MacOSX builds. Its the reason I haven't released binaries for 2.9.

alxpl · 2022-05-08T22:58:48Z

I wanted to create a 2.9.0 tag, but in the process I also made a release, which I deleted immediately afterwards.

highperformancecoder · 2022-05-09T01:56:05Z

Creating a tag automatically creates a release. Unless we formalise the release process, its probably best if I continue to do the releases. It gets confusing having multiple independent release numbering. OTOH, we could say collectively decide on a state of the master branch for a 2.X release, and then if I need to do any tweaks to the code to enable platform builds, bump the 3rd version number (2.X.1, 2.X.2 etc.) and PR those back into master. I have no objection to informal tags, though (eg "Alexs-2.9.0-release"). Cheers

…

On Sun, May 08, 2022 at 03:58:58PM -0700, alxpl wrote: I wanted to create a 2.9.0 tag, but in the process I also made a release, which I deleted immediately afterwards. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.*Message ID: <SciDAVis/ ***@***.***>

--

---------------------------------------------------------------------------- Dr Russell Standish Phone 0425 253119 (mobile) Principal, High Performance Coders ***@***.*** http://www.hpcoders.com.au ----------------------------------------------------------------------------

alxpl · 2022-05-09T02:14:32Z

Sorry, I did not mean to overstep. I thought that since you had named the commit "2.9 release" it was ok to tag it to keep track of things.
Semantic versioning is convenient for packaging as well, but what gets which version number is entirely up to you.

highperformancecoder · 2022-05-09T03:27:28Z

On Sun, May 08, 2022 at 07:14:43PM -0700, alxpl wrote: Sorry, I did not mean to overstep. I thought that since you had named the commit "2.9 release" it was ok to tag it to keep track of things. Semantic versioning is convenient for packaging as well, but what gets which version number is entirely up to you.

Didn't the tag go through with the PR? Sounds like a deficiency of git.

…

--

---------------------------------------------------------------------------- Dr Russell Standish Phone 0425 253119 (mobile) Principal, High Performance Coders ***@***.*** http://www.hpcoders.com.au ----------------------------------------------------------------------------

alxpl · 2022-05-09T08:46:11Z

No, the last tag was 2.4.0.

highperformancecoder · 2022-05-09T23:19:58Z

On Mon, May 09, 2022 at 01:46:22AM -0700, alxpl wrote: No, the last tag was 2.4.0.

It seems I have to push the tags separately, once the PR is merged. It's going to be easy to forget :(. "git push --tags upstream" Ah - the whole release stuff is new since I last looked. In the past, any tag was a release (you could download a zip or tarball) - that still applies, but now you can have releases with attached binaries, which is an attempt to do like SourceForge's file release system. I think I'll stick with the FRS for now, as its what people are used to. Cheers

…

--

---------------------------------------------------------------------------- Dr Russell Standish Phone 0425 253119 (mobile) Principal, High Performance Coders ***@***.*** http://www.hpcoders.com.au -----------------------------------------------------------------------------

highperformancecoder added 30 commits March 6, 2021 20:50

Attempt at using CPack to generate MacOSX bundle

e6d0a0b

Try adding -lm to GSL linked libs to solve OBS linking problem.

2e2f2a0

Restore the fucking translations!!!

56f90d9

Release 2.4.1

ea9a6d5

Merge branch 'master' of github.com:highperformancecoder/scidavis

0926b61

Release 2.4.2

f2210aa

MacOSX Bundle stuff.

8854d72

Merge branch 'master' into macosx-installer

d76b092

fix up MacOSX code signing issues

e1742f6

Release 2.5

958069b

More MacOSX bundle fixes

076da5c

Release 2.6

8fc63c5

Merge branch 'master' of github.com:highperformancecoder/scidavis

03e02dd

Release 2.7

5553099

Perform an addition rewrite_dylibs after macdeployqt

c37d8f7

Release 2.7.1

9548d2c

Repair translations

09aa5fc

Translations copied into proper location where scidavis expects them

0a05eca

Update obsCheck for Leap distros

Add built translatioin files to distribution tarball, to help where

45a7b29

linguist is not installed

Merge branch 'master' of github.com:highperformancecoder/scidavis

beeb7de

Restore chinese translations

3108329

Fixed up copy compiled translations

459f518

Fix finding qwt submodule on fresh install

b1529c9

Revert "Fix finding qwt submodule on fresh install"

e7e11c9

This reverts commit b1529c9.

Fix finding qwt submodule on fresh install

05e1aa0

Update translation to latest code

f318ab3

Revert clobber of chinese translations

4b91fe8

Release 2.8

f961910

Reinstate copy of translation files with a comment that it is to avoid

fee0333

lupdate clobbering the translations.

Merge branch 'master' of github.com:SciDAVis/scidavis

b08fff7

highperformancecoder added 2 commits April 16, 2022 17:32

Update reference data for tests

73438b5

Release 2.9.2

5bad72b

highperformancecoder requested review from alxpl, kevinsmia1939, narunlifescience, gbm19 and Suthiro April 16, 2022 07:42

highperformancecoder added 2 commits April 16, 2022 19:35

Issue mkdir before copy translations - helps for out of source builds.

37e4be4

don't fail if translations already exists

160b1b3

highperformancecoder added 3 commits April 17, 2022 09:20

Integrate CMakeLists.txt changes suggested by Alex.

1021793

Revert "Update reference data for tests"

baf0d38

This reverts commit 73438b5.

Fix reference to unittest executable in regression test script.

621ee90

narunlifescience approved these changes Apr 25, 2022

View reviewed changes

alxpl merged commit 9eece99 into SciDAVis:master May 8, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

SciDAVis 2.9 release #24

SciDAVis 2.9 release #24

Uh oh!

highperformancecoder commented Apr 16, 2022

Uh oh!

alxpl commented Apr 16, 2022

Uh oh!

highperformancecoder commented Apr 16, 2022

Uh oh!

Nowa-Ammerlaan commented Apr 21, 2022

Uh oh!

narunlifescience left a comment

Uh oh!

alxpl commented May 8, 2022

Uh oh!

alxpl commented May 8, 2022

Uh oh!

highperformancecoder commented May 8, 2022

Uh oh!

alxpl commented May 8, 2022

Uh oh!

highperformancecoder commented May 9, 2022 via email

Uh oh!

alxpl commented May 9, 2022

Uh oh!

highperformancecoder commented May 9, 2022 via email

Uh oh!

alxpl commented May 9, 2022

Uh oh!

highperformancecoder commented May 9, 2022 via email

Uh oh!

Uh oh!

Uh oh!

SciDAVis 2.9 release #24

SciDAVis 2.9 release #24

Uh oh!

Conversation

highperformancecoder commented Apr 16, 2022

Uh oh!

alxpl commented Apr 16, 2022

Uh oh!

highperformancecoder commented Apr 16, 2022

Uh oh!

Nowa-Ammerlaan commented Apr 21, 2022

Uh oh!

narunlifescience left a comment

Choose a reason for hiding this comment

Uh oh!

alxpl commented May 8, 2022

Uh oh!

alxpl commented May 8, 2022

Uh oh!

highperformancecoder commented May 8, 2022

Uh oh!

alxpl commented May 8, 2022

Uh oh!

highperformancecoder commented May 9, 2022 via email

Uh oh!

alxpl commented May 9, 2022

Uh oh!

highperformancecoder commented May 9, 2022 via email

Uh oh!

alxpl commented May 9, 2022

Uh oh!

highperformancecoder commented May 9, 2022 via email

Uh oh!

Uh oh!