QJournalctl win32 x64 port.

[alacasta]

What?

This is a contribution which aims to port the QJournalctl application to Windows.

Details

The major contribution is

• To provide an script and updated configuration to be able to build the application for Windows.
• To add an appveyor configuration to be able to directly obtain the released artifacts from there (deployed artifacts)

There are some few changes applied to the codebase:

• Migration of the usleep to a multi-platform equivalent call
• Minor modification from iniializing an array of size a variable, which is not compliant with the msvc build rules. Migrated to safer malloc based initialization.

Also to the README.md

• Unifying the type of Markdown Titles
• Reordering the building chapter
• Adding an specific Windows chapter

Remaining tasks

• To update the Changelog in case of performing a releease with these changes
• To integrate appveyor to the official repository.

[pentix]

As already stated in my previous email, I'd suggest some changes: 😌

• Fixing the "Save SSH connections" function
• Disabling all local systemd related functions for the Windows port
• Copy the detailed setup instructions into the README
• Prefix/Squash all "fix CI" commits together to keep the commit history somewhat structured
• Maybe some cosmetic changes in the autogen_and_build.bat script

[pentix]

Just some cosmetic issues actually

[pentix]

Is there an simple method to display the actually executed commands? This could get misleading/confusing if we log version A but execute version B...

[pentix]

What about adding call .....\.....\vcvarsall.bat x64 directly for the user? I guess the problem is we would need to find the correct installation path of Visual Studio, right? 😬

[pentix]

Before starting the build, it would be nice to have version.h adjusted just as the autogen.sh script does. (

qjournalctl/autogen.sh

Line 19 in 90e299a

if [ -d ".git" ]; then

)

However I'm almost sure there's a better (and more portable) way of doing this than what I'm doing right now...
(Maybe qmake itself offers a solution to this?)