How to include library using config+=mylibrary

[travlr]

To early in the morning me to fully describe why everything mentioned in this thread is poor programming practice and should be discouraged not encouraged.

Qt and Qmake (as well as certified developers) should know better!!

Installing user generated libraries and other dependencies directly into the Qt install directories is fragile and will break when for instance the Qt library is upgraded or deleted and re-installed.

Also, on Linux for instance, distribution based installs are installed with permission filters to the 'admin' of the system. Developers using the 3rd party library, may very well not want to be forced by the provider of a 3rd party, Qt based library, to have to install in this area, but instead in the less restricted 'user' space.

Another peeve I'll mention is that Qmake relies on hard coded Qt environment variables that are not available to the build environment outside of using Qmake itself. I constantly come across projects using qmake build configurations that I have to completely rewrite to make for a more flexible environment.

Qtcreator is a fine example of a crappy qmake build file. On Linux the install is in-flexible and has to be patched or deviated from. Qtcreator installs itself not in the 'admin' restricted area, but where only system related files belong.. /lib /include /bin ...etc!

Please consider this when you distribute your 3rd party projects using the very poorly created (and documented) qmake build system.

Please use system wide ENVIRONMENT variables and not hard coded Qt variables for others to rely on.

Thank you!

// rant over :-)

[marcvanriet]

@travlr. Thanks for your comment. However, you don't say how the 'right' way to do is in your opinion if you would write your own library. Or how 3d party libraries should do it.

As a sidenote : I have different builds of Qt on my systen (4.6.3 and 4.7.3). I build each 3rd party library I use with both versions. Therefore I think it is a GOOD idea to put the Qt build and the libraries in a common place. So that when you delete a Qt version you don't have to look for all the old libraries to delete. However I agree putting the binaries and include files of the 3rd party library together with the Qt ones is a bad idea. There may be a conflict between different 3rd party libraries, and cleaning this up when rebuilding or removing a library is cumbersome. Also, you may want to evaluate newer versions of a library without deleting the old one.

I am thinking of keeping a directory 'addons' in the Qt directory in which I put the includes and binaries of all libraries, each in their own subdirectory. The include and library paths can then easily be specified in your own .pro or in a pri or prl file.

Maybe the Trolls could specify some conventions regarding this, so that all 3rd party libraries can be installed in the same way without conflict.

Regards,
Marc

[wysota]

To early in the morning me to fully describe why everything mentioned in this thread is poor programming practice and should be discouraged not encouraged.

Please explain what exactly from this "everything" you consider poor programming practice otherwise following your approach everything you say is just trolling. So far I have only seen you touch the problem of installing addons inside Qt install directory. There is more to this thread than that.

Installing user generated libraries and other dependencies directly into the Qt install directories is fragile and will break when for instance the Qt library is upgraded or deleted and re-installed.

Considering the fact that Qt manual tells us to install Designer plugin to Qt's install tree by default, I don't care. If you upgrade/reinstall/modify Qt, you'll need to reinstall the 3rd party plugin anyway. If you choose to install the plugin in a self-contained environment, you are very welcome to do that, Qt/QMake give you such possibilities (also described in the manual). Considering the fact that 99% of the users will want the default behaviour, I think it is a sane decision to make it my default behaviour too. The remaining 1% of people is clever enough to alter the installation path using a simple call to qmake or make with proper arguments.

Also, on Linux for instance, distribution based installs are installed with permission filters to the 'admin' of the system. Developers using the 3rd party library, may very well not want to be forced by the provider of a 3rd party, Qt based library, to have to install in this area, but instead in the less restricted 'user' space.

True, however you could say the same about every library or other piece of software that installs itself into /usr or /usr/local subtree which also require superuser privileges. Considering the fact that all Linux distributions I know of install packages to /usr, /usr/local and /opt by default and most build environments are preconfigured to install the build in /usr/local, I really don't care that my software follows the same pattern and requires superuser rights to install by default. Please take a standard deb or rpm package containing glibc and have it install itself to /home/something keeping the functionality of the system without any need for manual tweaking. And to make things even more funny let's assume my home directory is encrypted and mounted/decrypted only when I log in.

Qtcreator is a fine example of a crappy qmake build file. On Linux the install is in-flexible and has to be patched or deviated from. Qtcreator installs itself not in the 'admin' restricted area, but where only system related files belong.. /lib /include /bin ...etc!

Funny, I can install Qt Creator wherever I want. It's as easy as calling "INSTALL_ROOT=/home/wysota/QtC make install".

By the way, not every developer is a Linux user. Don't require people to have knowledge about layout and policies of a Linux system just because you yourself use Linux. I'm sure you'd want Windows people to have a similar approach. If you can't satisfy everyone, find a largest common denominator. I think Qt does that pretty well.