[blfs-support] Latest news in GNOME world
bruce.dubbs at gmail.com
Thu Nov 15 08:50:50 PST 2012
> Interesting to hear others opinions on this. I personally felt both
> cmake and qt do too much to hard-code where they expect locations of
> files (such as libaries) should be. If you're coming from an
> enviroment where you value portable apps (such as programs just
> running from your flash drive), hard-coding file locations isn't a
> very desirable thing. While most KDE/qt programs do seem to use
> cmake, I'm running across quite a few qt apps that just use qmake.
> (Not sure that's all that much better of an option, since you still
> have hard-coded paths.) I've even run across a few that use gnu
I worked on a (set of) program(s) for about three years based on qt3 and
later qt4. qmake was used. There were two modes: generate the .pro
file and generate the Makefile. Generating the .pro file is only
marginally useful at the first build of a system/platfrom combination.
After that, manual editing of the .pro files was needed.
In our case, we needed to use the same code to port to Win, Mac, and
Linux, but the development system was, of course, Linux. Using qmake to
generate Makefiles was quite easy and useful. There are custom settings
that are needed to allow the Makefile to find the Qt includes and
libraries. That was fairly easy to manage with a .pri (profile incldue)
file. It was a bit more than CMMI though.
In that case, moving to cmake would not have made sense. Trying to use
autotools would have been much more difficult.
More information about the blfs-support