[blfs-support] Latest news in GNOME world

Bruce Dubbs bruce.dubbs at gmail.com
Thu Nov 15 08:50:50 PST 2012


LM wrote:

> 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
> autotools.

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.

   -- Bruce



More information about the blfs-support mailing list