mxklb / cuteproject Goto Github PK

Github creates a release for each git tag which actually only contains the source code.

Github releases shall contain:

• a release note
• links to release artifacts (.deb, .AppImage, .dmg, .exe)

Github releases shall be generated automatically by the CI. So simply pushing a tag to the repo shall trigger the release (including release note and artifacts linking).

This needs

• A branching model (tbd) and its
• according CI config changes +
• packaging changes (changelog & version numbering)

Actually coverage flags are used on linux only.

OSX shall follow ..

Can be done when #7 is fixed ..

Deploying Linux binaries as in the AppImage format would have, among others, these advantages:

• Applications packaged as an AppImage can run on many distributions (including Ubuntu, Fedora, openSUSE, CentOS, elementaryOS, Linux Mint, and others)
• One app = one file = super simple for users: just download one AppImage file, make it executable, and run
• No unpacking or installation necessary
• No root needed
• No system libraries changed
• Works out of the box, no installation of runtimes needed
• Optional desktop integration with appimaged
• Optional binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate
• Can optionally GPG2-sign your AppImages (inside the file)
• Works on Live ISOs
• Can use the same AppImages when dual-booting multiple distributions
• Can be listed in the AppImageHub central directory of available AppImages
• Can double as a self-extracting compressed archive with the --appimage-extract parameter

Here is an overview of projects that are already distributing upstream-provided, official AppImages.

The linuxdeployqt tool can be easily integrated with Travis CI to produce AppImages of Qt applications.

If you have questions, AppImage developers are on #AppImage on irc.freenode.net.

Actually the debian changelog is at its initial state.

This results in the debian source version to be the semantic bugfix version (third version number), always followed by "-1". This can be verified by checking the output of pkgs/debian.sh (dpkg-buildpackage). For example all 1.0.5 versions always create the same source version:

..
dpkg-buildpackage: info: source version 5-1
..

The debian source version shall always be the commit counter (cc) shown by the output of git describe --long. For example the output "1.0.5-15-g39373ce" say's there are 15 commits till version 1.0.5. So this information shall be parsed to dpkg-buildpackage so that the semantic bugfix version is in that case followed by "-15". For example versions above 1.0.5 create debian source versions like:

..
dpkg-buildpackage: info: source version 5-cc
.. 

Therefore the debian/changelog file shall be setup properly to reflect this.

Actually only msvc2015 is used/verified for win32 compilations.

Besides appvoyer shall also build with minGW (and compile test coverage report)

.qmake.conf shall be substituted with globals.pri as done in rtaudiostreamer

It shall be verified that resulting .app bundles are installable on non developer OS.

To further increase the learning curve of the multi OS deployment process qt libs shall be involved.

So simply creating a small UI for the main app shall feed this need ..

It would be nice to have a script to automatically generate .deb packages

Actually it looks like coverage isn't generated properly.

The .gcno files are located in the directory where the .o object files are located (and not besides the class cpp files they're named as). So in the actual coverage report only one test main.cpp is shown. This indicates that there is something messed up with the code coverage generation.

After calling macdeployqt, all used qt5-framework linker path are messed up:

app/cuteproject.app/Contents/MacOS/cuteproject
 
objc[13993]: Class RunLoopModeTracker is implemented in both /usr/local/Cellar/qt5/5.7.0/lib/QtCore.framework/Versions/5/QtCore and /Users/xamblak/Develop/cuteproject/app/cuteproject.app/Contents/Frameworks/QtCore.framework/Versions/5/QtCore. One of the two will be used. Which one is undefined.
objc[13993]: Class NotificationReceiver is implemented in both /Users/xamblak/Develop/cuteproject/app/cuteproject.app/Contents/Frameworks/QtWidgets.framework/Versions/5/QtWidgets and /usr/local/Cellar/qt5/5.7.0/lib/QtWidgets.framework/Versions/5/QtWidgets. One of the two will be used. Which one is undefined.
QObject::startTimer: Timers cannot be started from another thread
QPixmap::scaled: Pixmap is a null pixmap
QPixmap::scaled: Pixmap is a null pixmap
QPixmap::scaled: Pixmap is a null pixmap
QPixmap::scaled: Pixmap is a null pixmap

This must be common problem with macdeployqt ..

Actually artifacts are published to different providers.

• linux artifacts (.deb & .AppImage) are stored @ gitlab build artifacts
• windows artifacts (.exe) are stored @ appvoyer build artifacts
• macOS artifacts (.dmg) are stored @ git (osx-deploy branch)

There shall be one place to store artifacts.

• Each of these artifacts shall be persisted at one common place/provider.
• Releases (tags) and continuous artifacts shall have different places/repositories.

For windows deployment UX there shall be an installer.

Actually plain folder structure is zipped and deployed.

Actually windows builds on appvoyer use msvc2015 compiler.

Test coverage/reports as on unix (lcov) seems not to be available.

There shall be another option to get test coverage with msvc compiler

Actually this project is only tested and developed primary linux and osx.

Windows builds shall get verified ..

Actually when someone want's to use cuteproject as a starting point for its own Qt5/C++ development its somehow complicated to do this. What needs to be done is renaming a lot of files and configurations, so that personal libs and app names are adjusted according to ones needs. This process shall be analysed to be automated.

Ideas are:

• there could be a config file (yml) containing meta data (project name, app name, gh-user, creds ..)
• there could be another repo containing cuteproject as a sub-module (to implement this issue)

Ideally there would be one single configure script (bash?) to prepare cuteproject for re-usage.