Ubuntu 18 packages do not meet version requirements (C++)

[ForeverRainbow]

Hi Ubuntu 18 lacks the packages required to build cherrytree from source. Most notably it lacks cmake 3.13.2 (I built 3.18 from source to get around this) and glibmm-2.4 is v2.56.0 (minimum is 2.64).

I am wondering whether these are arbitrary version limits since 2.64 is not required for gtkmm3 (afaik 2.64 is actually for gtkmm4) and is the latest stable release. Also the cmake file doesnt look like it needs that recent a version (I have no idea what its minimum might be but the one on ubuntu 18 is 3.10.something).

[ghost]

Ubuntu 18 lacks the packages required to build cherrytree from source. Most notably it lacks cmake 3.13.2

Current Ubuntu LTS is 20 called 'focal', not 18. => cmake (3.16.3-1ubuntu1)

Then upgrade Ubuntu from bionic (18.04LTS) to focal (20.04LTS)

sudo sed -i 's/bionic/focal/g' /etc/apt/sources.list
sudo apt update
sudo apt upgrade

[ForeverRainbow]

@ciranus Thanks, I know that the latest is 20. But ubuntu 18 will be supported for another 3 years still and unless these package versions are actually the minimum required then there is no reason why it shouldnt build on 18.

When I said "the latest stable release" I was talking about glibmm (2.64 is the latest stable, 2.65 the latest unstable)

[ghost]

I wonder why you don't want to upgrade to 20-LTS. Don't see any problem. You can at least add focal to sources.list, and install the packages you need from focal. Until you don't 'apt upgrade', you will still use a 'bionic' basis. Well, it's up to you....

[ForeverRainbow]

@ciranus Doing a full system upgrade to build a single application? (Oh yeah thats why I switched to fedora lol) in all seriousness I could just change the versions in the cmake file, when I have a minute I will so I can test what the minimums actually are. This issue is more just making people aware of this and a possible reference for a fix later.

Also packages have to be built on the oldest version of the distro they want to support (due to having correct versions of libc or at least I think thats the reason) so if cherrytree cannot be built on ubuntu < 20 then only ubuntu 20+ would be supported, which would not be great :p

[ghost]

Cherrytree gtk2 is available for old bionic, then really not a problem https://packages.ubuntu.com/bionic/cherrytree

Why would you need a specific gtk3 release for bionic is not clear to me. I'm just afraid you are looking for unnecessary complexity. Only my 2 cents.

[giuspen]

Glib/Glibmm requirement is for a useful method to canonicalise the filepaths being used in cherrytree. I will build the Gtkmm3 version also into flatpak when it will replace the Pygtk2 version so that will run everywhere including 18.04.

[MJimitater]

@ciranus actually I have an old laptop running Ubuntu 18.04. and it is not my intention to upgrade to 20.04., and I would very much appreciate the C++ version of CT on it. I actually did encounter this same building error, thanks for pointing out this issue @ForeverRainbow. A flatpak version will of course be sufficient for any distro

[ForeverRainbow]

@giuspen Yes I ran into that problem when trying it.

Also gtkmm 3.24 is needed for FileChooserNative, it could just be replaced by FileChooserDialog with a macro but if flatpak is going to be used anyway then not much point :p. I think >=3.24 should be put on gtkmm in the cmake file though.

[ForeverRainbow]

glibmm 2.64 is dated 2020-03-17 (from gnome sources) so I assume it may also be an issue on older versions of mac or anything which doesn't do cutting edge.

There are things like snap for mac which would work but it seems kinda silly that we need such a new version for a single function (a function which is defined in the filesystem standard no less). If reducing the version ever does become a priority then something like ghc::filesystem or boost::filesystem could be used instead of glib (see #916 for why std::filesystem can't be used on mac). or std::filesystem could be used on non-mac systems and glibmm 2.64 be needed for mac (since everything uses the fs interface anyway this should (fingers crossed :p) be a trivial macro check)

[ghost]

If you allow me one more comment to better explain what I had in mind... GTK history:

• GTK+ 1 : 1998
• GTK+ 2 : 2002
• GTK+ 3 : 2011
• GTK+ 4 : 2020 / see GTK4 News or GTK+ 4 Reference Manual

CT-gtk3 has been let's say "a bit delayed", and CT has been removed from all distribution current repositories. Example: tracker.debian.org/pkg/cherrytree

In term of priority, it looks to me that new CT should be much more concentrated to its future, than spending time to backport a new dev version to old ubuntu release. Ubuntu will never mix gtk2 and gtk3 CT releases in bionic 'official' repositories.

Backport to older distribution releases is usually a separate work which should not add any regression or improvement limitation, and add too much maintainability complexity with bloated code to the current code.

I personally use Debian called "unstable" (which does not mean 'unstable' in Debian language), and have ubuntu Groovy installed on another partition (bionic > focal > groovy). Still not clear to me why CT-gtk3 backport to old "bionic" is right now so important, but this is another debate.

[ForeverRainbow]

@ciranus I agree that functionality should not be waved because it would require a newer system. Feel free to checkout my proposed changes, they involve two encapsulated macro checks and moving a line from future/CMakeLists.txt -> future/src/ct/CMakeLists.txt. If you feel that is too much please comment on them and tell me how/if they can be improved.

[ghost]

It is absolutely not up to me to decide anything related to the code: it's up to the code owner !! If giuspen says its' fine, then it is ! Consider just my comments as background feeling related to CT timeframe, between gtl2 and ... gtk4.

Why is it a problem for someone writing code to have the right tool and the right libraries is still not clear to me, but again, not the debate here.

[giuspen]

@ciranus I actually very much agree with your analysis, the future version is very much oriented to the future and I would not have spent time myself on making it build on older systems. On the other hand, I think that @ForeverRainbow made a nice job which would be a shame to bin because some people for various reasons stuck with an older system can now test and contribute without the need of the flatpak framework

[giuspen]

@ForeverRainbow since you made this good work I think it would be a good idea to also edit https://github.com/giuspen/cherrytree/blob/master/.travis.yml to build also bionic in parallel to focal

[giuspen]

BTW it should no longer be necessary to download and rebuild cmake:

      linux)
        export DEPS_DIR="${HOME}/deps"
        mkdir -p ${DEPS_DIR} && cd ${DEPS_DIR}
        export CMAKE_URL="https://github.com/Kitware/CMake/releases/download/v3.17.0/cmake-3.17.0-Linux-x86_64.tar.gz";
        mkdir cmake;
        travis_retry wget --no-check-certificate -O - ${CMAKE_URL} | tar --strip-components=1 -xz -C cmake;
        export PATH=${DEPS_DIR}/cmake/bin:${PATH};
        echo ${PATH};
        cmake --version

[ForeverRainbow]

@giuspen Is there a reason that the apt packages are installed via a script rather than with the apt addon? Wondering if I should change that is all

[giuspen]

@ForeverRainbow I don't think so, we are not experts in Travis CI you are free to experiment all we care is that it builds and runs the unit tests

[ForeverRainbow]

@giuspen I think I will not mess with it xD, if it works it works

[droid192]

build on buster deb10 not possible as well:

-- CT_VERSION = 0.99.25
Tests are ON
-- Checking for module 'glibmm-2.4>=2.64'
--   Requested 'glibmm-2.4 >= 2.64' but version of glibmm is 2.58.0
You may find new versions of glibmm at http://www.gtkmm.org/
CMake Error at /usr/share/cmake-3.13/Modules/FindPkgConfig.cmake:452 (message):
  A required package was not found
Call Stack (most recent call first):
  /usr/share/cmake-3.13/Modules/FindPkgConfig.cmake:622 (_pkg_check_modules_internal)
  CMakeLists.txt:101 (pkg_check_modules)

with bullseye late next year, presumably resolved bullseye: 2.64.2-2; until then..mmh