Builds for Linux

[ghost]

Could you make binary builds for Linux?

Maybe you could setup Travis Ci for autobuild .AppImage package?

[ikskuh]

Hey!
I could upload my own builds, but i'm not sure if they'll work out of the box on other computers (because Qt versions and stuff).

I've also learned that VersaTile won't run on current Ubuntu systems because they still have an older version of Qt which doesn't have the QOpenGLWidget and still uses the QGLWidget...

But i'll look into it!

[aggsol]

Building on the current Ubuntu LTS requires a newer Qt(Creator). Some CI would be great though. See the wiki: https://github.com/MasterQ32/VersaTile/wiki/How-To-Build

[ikskuh]

Yeah, i'll take a look! Does one of you use Travis CI already? Would be cool to have some help

[ghost]

Does one of you use Travis CI already? Would be cool to have some help

I already use it

• https://github.com/symbian9/azpainter

@probonopd, could you help @MasterQ32 to setup Travis CI for producing AppImage?

P.S.: there are few ways upload built binary back to Github

• https://github.com/mkulesh/microMathematics/tree/master/autobuild
• https://github.com/probonopd/uploadtool

[ghost]

Building on the current Ubuntu LTS requires a newer Qt(Creator).

@aggsol, try use 'portable' Qt5.9 on Ubuntu 16.04 LTS (using offline installer)

• https://download.qt.io/official_releases/qt/5.9/
  • https://download.qt.io/official_releases/qt/5.9/5.9.0/qt-opensource-linux-x64-5.9.0.run
• https://download.qt.io/official_releases/qtcreator/4.4/
  • https://download.qt.io/official_releases/qtcreator/4.4/4.4.0/qt-creator-opensource-linux-x86_64-4.4.0.run

[aggsol]

Another idea, how about using https://snapcraft.io/? There way more packages would emerge?

[ikskuh]

I'll try it. I've struggeled with travis a lot yesterday... I now have a built with missing linker references because of bad maintaince of packages on ubuntu

[ikskuh]

Hm, doesn't seem very different in terms of build features... I'll try to do some custom CI server as soon as i'm home again, wanted to something with virtualisation anyways

[probonopd]

It should be rather easy to use Travis CI and linuxdeployqt as described at https://github.com/probonopd/linuxdeployqt/blob/master/README.md. There are also many examples linked.

As for Qt 5.9, you can use the ppa that I also use in my examples there.

@MasterQ32 please let me know if you run into any issues, I'm happy to help. AppImage developers are also on #AppImage on irc.freenode.net.

[ikskuh]

Well, i still struggle with even building versatile because of much outdated libraries provided with Travis CI...
And i don't want to built all of them on each compilation run

[ikskuh]

You may take a look here: https://travis-ci.org/MasterQ32/VersaTile/builds/280935405

[probonopd]

Yes, it is good practice to build against the oldest libraries you can still build against, in order to maximize compatibility with older target systems. Hence it may be easier to use the oldest still-supported Ubuntu LTS version during development, in order not to unknowingly incur dependencies on "bleeding edge" stuff that later need to be carefully removed/backported.

[ikskuh]

And that's where the problems start... I'm using arch linux which means i always have the bleeding edge versions of all libraries. So i could create a build for arch/"bleeding edge" or ubuntu/"quite old" and the versions would be incompatible.
So it would each would either run on arch or on ubuntu, but never both (except for some smaller cases or static linking)
I face the problem the other way round. Most games are dynamically linked against older versions of libraries and i can't play them because i don't even have the old versions of those libraries in the packaging system...

I don't really know what to do, as i don't like to use older version of libraries (because of security bugs, stability, ...) but i also want to support non-archlinux systems

[probonopd]

Since linuydeployqt can bundle the libraries that cannot be expected to be part of each target system inside the AppImage, "i don't even have the old versions of those libraries in the packaging system" will not be a problem if you are running AppImages on Arch. The libraries that are missing from the packaging system will be inside the AppImages. So most of the time AppImages should run on Arch just fine.

As for making what goes into AppImages, Arch and other rolling release distributions are not suitable. Quite the contrary, we recommend to use the oldest still-supported enterprise or LTS versions like CentOS 6 or Ubuntu 14.04, in order to maximize compatibility with different target systems. This is because applications compiled on older systems will continue to run on newer systems (at least if correctly bundled as AppImages), while the reverse is not true.

So for application development work, rolling release distributions like Arch are not the first choice if you want to develop applications that also run on older target systems (without having to bundle everything).

[ikskuh]

So where's the exact difference between an app image and static linking?

[probonopd]

Static linking links libraries into the executable. AppImage merely puts the executable, libraries, images, icons, fonts, sounds etc. into a self-mounting filesystem image (think of an ISO that mounts itself and executes whatever is inside).

You can put statically or dynamically linked applications into an AppImage.

[probonopd]

What is the status on this?

[ikskuh]

Haven't continued working on it as it has low priority for me and i'm short at time anyways