octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fwd: Successfully merged projects


From: Jacob Dawid
Subject: Fwd: Successfully merged projects
Date: Mon, 11 Apr 2011 18:34:03 +0200



---------- Forwarded message ----------
From: Jacob Dawid <address@hidden>
Date: 2011/4/11
Subject: Re: Successfully merged projects
To: "John W. Eaton" <address@hidden>


wysota in the QtCentre forums says this:

Let's face it - cmake is a next generation tool compared to qmake just as qmake is a next generation tool compared to autotools or tmake. So this is obvious that many things are easier to obtain with cmake than with qmake because the former learned from the experience gathered by the latter. But this all doesn't change a fact that if you want to deploy a Qt based application in a foreign environment it is easier to do it using qmake than using cmake once you have the build infrastructure set up properly. So this is really a battle between easing the development stage and easing the installation stage. From what I've seen on QtCentre the latter yields more problems thus it is better if one experienced developer battles with qmake than if dozens of unexperienced Windoze end-users battle with both cmake (and its dependencies) and the final application itself. And let's not forget Qt needs to be deployed as well (in both cases).

So to sum things up - for Qt only applications I will prefer qmake over cmake as long as qmake is a standard build tool for Qt. For KDE4 applications I will prefer cmake over anything else because I'm not smart enough to setup my own build infrastructure for KDE applications. For other uses I can use either one or the other or even write a dedicated Makefile if neither is available. Let's face it - cmake is a next generation tool compared to qmake just as qmake is a next generation tool compared to autotools or tmake. So this is obvious that many things are easier to obtain with cmake than with qmake because the former learned from the experience gathered by the latter. But this all doesn't change a fact that if you want to deploy a Qt based application in a foreign environment it is easier to do it using qmake than using cmake once you have the build infrastructure set up properly. So this is really a battle between easing the development stage and easing the installation stage. From what I've seen on QtCentre the latter yields more problems thus it is better if one experienced developer battles with qmake than if dozens of unexperienced Windoze end-users battle with both cmake (and its dependencies) and the final application itself. And let's not forget Qt needs to be deployed as well (in both cases).

So to sum things up - for Qt only applications I will prefer qmake over cmake as long as qmake is a standard build tool for Qt. For KDE4 applications I will prefer cmake over anything else because I'm not smart enough to setup my own build infrastructure for KDE applications. For other uses I can use either one or the other or even write a dedicated Makefile if neither is available.

Source: http://www.qtcentre.org/threads/21268-qmake-versus-CMake
I think that's a rather realistic conclusion.

--
Software Development == Church Development
Step 1. Build it.
Step 2. Pray.

Whitespace - the most ink saving programming language: http://compsoc.dur.ac.uk/whitespace/index.php .




--
Software Development == Church Development
Step 1. Build it.
Step 2. Pray.

Whitespace - the most ink saving programming language: http://compsoc.dur.ac.uk/whitespace/index.php .


reply via email to

[Prev in Thread] Current Thread [Next in Thread]