Qt module project structure

[Skycoder42]

This pull request aims to refactor the project structure to make it build as a "Qt module". It's a first step to get this tool closer to Qt.

The main advantage here is: Simply running:

qmake
make
make install

will compile and install the tool into your Qt installation, and make it a part of your Qt just like any other tool (qmake, etc.)

[TheAssassin]

This PR is blocked by #127. Please wait for that PR to be merged, then you'll have to update this one. Looks like it's anyway conflicting.

[TheAssassin]

PR #127 has been merged, so you can update your PR now.

I'd suggest to replace qmake by CMake completely completely to improve the integration with other tools. E.g., we're intending to replace AppImageUpdate's and zsync-curl's build system with it, and it would be nice to have the same tool used across all related projects. But as I am aware of #84, and thus won't try to establish CMake.

Also, please don't suggest to build in-source (like you did with your example), that's a general rule of thumb. It leads to a vast amount of problems in my experience, you should generally avoid it. I know that the Travis config does that at the moment, but we're going to change that soon anyway.

To simplify the structure, I'd just put all sources and headers in the same directory. We don't really have to split it up. But moving them to the same directory is a first step.

[Skycoder42]

I'll wait until #125 is merged, then I will check how much of this PR is still relevant, and update it accordingly

[Skycoder42]

I updated to the latest master.

Since #125 seems to be stale, I made this PR ready to merge. But before you do, a few words to explain the PR:

• The general project structure follows the style of general Qt Modules
  • The src folder is needed, as qmake won't parse the project if it does not exist
  • The linuxdeployqt code is now inside of tools, as that's where Qt puts general tools
• The .qmake.conf contains general project configurations that can change per system. It's basically additional variables for qmake that are applied on any subproject qmake file. Right now, it contains the module version.
  • I chose 0.5.0 as version (based on the existing releases), but this can of course be adjusted.
• No changes (except for includes) have been made to the actual source files.

And one more, rather important thing:

• As far as I understand, Qt internally uses perl to figure out some build parameters. As such, it's possible that perl has become a requirement for qmake to run properly. If that's a nogo, I can try to find a distro without perl, and test if it's possible without. But as far as I know, perl is present on basically any linux.

Edit: The codacy warnings are not mine, they come from the master branch

[Skycoder42]

Oh, and @TheAssassin regarding the build in source - it was just for simplicity. I do not build in source myself. (But as far as I know, The Qt module setup tries to prevent such problems through it's setup)

[probonopd]

Thanks @Skycoder42

[Skycoder42]

Ah, one more thing: You might already have seen it in travis, but to build both the tool and all tests, one can simply run make all in the projects root directory (the normal make builds without the tests). This could be useful for the readme as well.

[probonopd]

To this very day I do not understand what the advantage of this "Qt module project structure" actually is. Apparently it just makes stuff more complicated compared to what we had before. @Skycoder42 can you please explain the motivation behind this PR?

install the tool into your Qt installation

Do we really want that? I mean, we are producing an AppImage of linuxdeployqt...

[probonopd]

This seems to be causing

WARNING: /home/travis/build/probonopd/linuxdeployqt/linuxdeployqt.pro:1: Unable to find file for inclusion qt_parts

Reference:
https://travis-ci.org/probonopd/linuxdeployqt/builds/326086539#L2220

[Skycoder42]

The idea behind this was that if you ever contribute this to Qt, you already have the project structure that is required for that. If you check the different pro files, you will see a bunch of load(...) lines, that load special Qt features to build it as a part of Qt.

The warning means that the qt_parts qmake feature is not available, which indicates a Qt installation that is not meant for compiling additional Qt modules (or is corrupted).

As long as you're not planning to actually contribute, there is not much of an advantage. I personally am using linuxdeployqt for deployment only, and not to generate an AppImage, just like I use windeployqt and macdeployqt. In that role, it fits pretty well as "Qt internal tool" that is compiled with Qt. And having it as part of the Qt installations makes shure it always uses the correct qmake etc.

[probonopd]

Thanks for the clarification @Skycoder42. Can you tell me how to build linuxdeployqt using the Qt from qt.io? Because that is what I am trying to do.

[Skycoder42]

That should work. I am using it myself in a build where I build the continous linuxdeployqt release (See https://travis-ci.org/Skycoder42/qpmx/jobs/301567325#L1381) and I don't get that error and the build succeeds.

Maybe try to explicitly invoke the qmake installed? or add wich qmake && qmake -v to make shure the correct qmake is used.

EDIT: I use /path/to/qmake && make qmake_all && make to build. You can compare my build script with yours from here: https://github.com/Skycoder42/QtModules/blob/master/ci/linux/setup/setup-gcc.sh#L22