Replace qmake with cmake??

[Giorgos Tsiapaliwkas]

Hello,

from time to time i have heard rumours tha Qt5 will use cmake instead of
qmake.
Is that correct?

I believe that it is pointless to mention the pros of cmake and the big
feedback that it receives.

thanks in advance

[Thiago Macieira]

Post by Giorgos Tsiapaliwkas
Hello,
from time to time i have heard rumours tha Qt5 will use cmake instead of
qmake.
Is that correct?

No. No decision has been made to move. So for the moment we stick to what we
have.

But if someone did the work and proved it to work, we probably wouldn't say
no.

[l***@nokia.com]

Post by Thiago Macieira

Post by Giorgos Tsiapaliwkas
Hello,
from time to time i have heard rumours tha Qt5 will use cmake instead of
qmake.
Is that correct?

No. No decision has been made to move. So for the moment we stick to what we
have.

Let's not change this for 5.0. Changing the build system is something that
can be potentially rather disruptive to our work. We'd then deal with both
changing larger pieces in the architecture as well as a changing build
system. It's better to look at options there once Qt itself has a stable
branch to work with again (ie. after we have 5.0).

Cheers,
Lars

Post by Thiago Macieira
But if someone did the work and proved it to work, we probably wouldn't say
no.

[Stephen Kelly]

Post by l***@nokia.com

Post by Thiago Macieira

Post by Giorgos Tsiapaliwkas
Hello,
from time to time i have heard rumours tha Qt5 will use cmake instead of
qmake.
Is that correct?

No. No decision has been made to move. So for the moment we stick to what we
have.

Let's not change this for 5.0. Changing the build system is something that
can be potentially rather disruptive to our work. We'd then deal with both
changing larger pieces in the architecture as well as a changing build
system. It's better to look at options there once Qt itself has a stable
branch to work with again (ie. after we have 5.0).
Cheers,
Lars

Post by Thiago Macieira
But if someone did the work and proved it to work, we probably wouldn't say
no.

These responses are interesting.

The last time this subject came up (with an offer from the CMake developers
to do the work), the response was "no way, we're never going to use CMake.
We will use the buildsystem we're working on as a research project instead".

What changed?

Would you really change the buildsystem in a 5.x release? I don't think you
would. It makes far more sense to not inhibit the work before 5.0.

[Frans Klaver]

Post by Stephen Kelly
Would you really change the buildsystem in a 5.x release? I don't think you
would. It makes far more sense to not inhibit the work before 5.0.

That's more or less exactly what Lars K. stated. It would only make
sense to decouple a build system change from a coding/architecture
change.

[Thiago Macieira]

Post by Frans Klaver

Post by Stephen Kelly
Would you really change the buildsystem in a 5.x release? I don't think you
would. It makes far more sense to not inhibit the work before 5.0.

That's more or less exactly what Lars K. stated. It would only make
sense to decouple a build system change from a coding/architecture
change.

I don't think that's what Stephen meant. He meant that he doesn't believe a
buildsystem change could happen after 5.0, so it would be best to do it now.

I disagree. I think we can change the buildsystem later. In fact, we'll have
to -- qmake is old and in need of replacement and the configure script is
beyond unmaintainable.

[Oswald Buddenhagen]

Post by Stephen Kelly
The last time this subject came up (with an offer from the CMake developers
to do the work), the response was "no way, we're never going to use CMake.

this is actually still true. everyone in qtdf who actually has something
to do with build systems has a strong dislike for cmake. the reasons are
widely documented in blog posts and numerous mails on this list.

Post by Stephen Kelly
We will use the buildsystem we're working on as a research project instead".

rumors. ;)

Post by Stephen Kelly
Would you really change the buildsystem in a 5.x release?

as others pointed out, we would. the build system is orthogonal to the
actual code.

Post by Stephen Kelly

Post by Thiago Macieira
But if someone did the work and proved it to work, we probably
wouldn't say no.

actually, we would. we did before: a complete cmake "port" of qt creator
was offered, and rejected.

[Stephen Kelly]

Post by Oswald Buddenhagen

Post by Thiago Macieira
But if someone did the work and proved it to work, we probably
wouldn't say no.

actually, we would. we did before: a complete cmake "port" of qt creator
was offered, and rejected.

Yes, this is what I expected as a first reply to the OP.

Qt on CMake is very very unlikely. Don't expect it to ever happen (though I
of course wish it would).

[Thiago Macieira]

Post by Stephen Kelly
Qt on CMake is very very unlikely. Don't expect it to ever happen (though I
of course wish it would).

And I'm challenging that by saying:

Qt on qmake is unbearable as a long-term solution.

[Stephen Kelly]

Post by Thiago Macieira

Post by Stephen Kelly
Qt on CMake is very very unlikely. Don't expect it to ever happen (though
I of course wish it would).

Qt on qmake is unbearable as a long-term solution.

Right. I can't really comment on the qmake & ./configure solution for Qt.
I've always avoided learning anything about the internals of it :).

Just for everyones clarity, I don't have any say in this or any say in
whether CMake is the answer for Qt.

My impression that Qt would not use CMake is based on reading this thread
and talking to ossi:

http://thread.gmane.org/gmane.comp.lib.qt.qt5-feedback/204

As far as I knew, that was the latest from Nokia (who even after opengov
launches will still have all the influence in things like this), and I don't
know of any changes from the position taken in that thread.

I just didn't want someone who missed that thread to think that all it takes
is for someone to do the work. It is clearly more complex than that.

Thanks,

Steve.

[Alexander Neundorf]

Post by Stephen Kelly

Post by Thiago Macieira

Post by Stephen Kelly
Qt on CMake is very very unlikely. Don't expect it to ever happen
(though I of course wish it would).

Qt on qmake is unbearable as a long-term solution.

Right. I can't really comment on the qmake & ./configure solution for Qt.
I've always avoided learning anything about the internals of it :).
Just for everyones clarity, I don't have any say in this or any say in
whether CMake is the answer for Qt.

Just as a note: CMake 2.8.6, which will be released this week, will have
built-in automoc functionality, so moc-handling will be as easy as it is with
qmake.

Alex

[Thiago Macieira]

Post by Alexander Neundorf
Just as a note: CMake 2.8.6, which will be released this week, will have
built-in automoc functionality, so moc-handling will be as easy as it is
with qmake.

Meaning we don't have to deploy automoc or meaning that we don't have to even
tell cmake that we want moc to be run, it will know from the presence of
Q_OBJECT in the files?

[Stephen Kelly]

Post by Thiago Macieira

Post by Alexander Neundorf
Just as a note: CMake 2.8.6, which will be released this week, will have
built-in automoc functionality, so moc-handling will be as easy as it is
with qmake.

Meaning we don't have to deploy automoc or meaning that we don't have to
even tell cmake that we want moc to be run, it will know from the presence
of Q_OBJECT in the files?

Meaning you don't have to deploy automoc. You do have to tell CMake to run
moc though by either

1) Before any add_library calls on whose source moc should be run:

set(CMAKE_AUTOMOC True)

(This is what we already do in KDE frameworks 5)

2) Or

set_target_properties(
qt_based_library_foo
qt_based_library_bar
PROPERTIES AUTOMOC True
)

For any specific targets.

[Frans Klaver]

Post by Stephen Kelly
set(CMAKE_AUTOMOC True)

Tested this one and it looks pretty promising. However, I would say that
as soon you include Qt4 in your project, you want automoc. Was there a
reason FindQt4 doesn't automatically set this? Speed considerations?

[Stephen Kelly]

Post by Frans Klaver

Post by Stephen Kelly
set(CMAKE_AUTOMOC True)

Tested this one and it looks pretty promising. However, I would say that
as soon you include Qt4 in your project, you want automoc. Was there a
reason FindQt4 doesn't automatically set this? Speed considerations?

I don't think that's the reason. The feature is just brand new and hasn't
appeared anywhere yet. Also, it may try to run automoc (but not moc) on non-
Qt dependent targets if you use CMAKE_AUTOMOC True. That's not a problem of
course but it may take a second or two, and you can still disable it on
files by using the SKIP_AUTOMOC property.

If it were me, I would set it in the ${QT_USE_FILE} (along with
CMAKE_INCLUDE_CURRENT_DIR for out of source builds. But I also don't know if
that would be source incompatible with existing buildsystems.

These are things to deal with in CMake really though.

Thanks,

Steve.

[Frans Klaver]

Post by Stephen Kelly

Post by Frans Klaver
Tested this one and it looks pretty promising. However, I would say that
as soon you include Qt4 in your project, you want automoc. Was there a
reason FindQt4 doesn't automatically set this? Speed considerations?

I don't think that's the reason. The feature is just brand new and hasn't
appeared anywhere yet. Also, it may try to run automoc (but not moc) on non-
Qt dependent targets if you use CMAKE_AUTOMOC True. That's not a problem of
course but it may take a second or two, and you can still disable it on
files by using the SKIP_AUTOMOC property.
If it were me, I would set it in the ${QT_USE_FILE} (along with
CMAKE_INCLUDE_CURRENT_DIR for out of source builds. But I also don't know if
that would be source incompatible with existing buildsystems.

Aye, that sounds reasonable.

[Bill Hoffman]

Post by Stephen Kelly

Post by Frans Klaver
Tested this one and it looks pretty promising. However, I would say that
as soon you include Qt4 in your project, you want automoc. Was there a
reason FindQt4 doesn't automatically set this? Speed considerations?

I don't think that's the reason. The feature is just brand new and hasn't
appeared anywhere yet. Also, it may try to run automoc (but not moc) on non-
Qt dependent targets if you use CMAKE_AUTOMOC True. That's not a problem of
course but it may take a second or two, and you can still disable it on
files by using the SKIP_AUTOMOC property.
If it were me, I would set it in the ${QT_USE_FILE} (along with
CMAKE_INCLUDE_CURRENT_DIR for out of source builds. But I also don't know if
that would be source incompatible with existing buildsystems.

I would say it is both speed and backwards compatibility. Most CMake
based projects do not use automoc. They use QT4_WRAP_CPP, like this:

QT4_WRAP_CPP(MOC_SRCS file.h file2.h )
ADD_EXECUTABLE(mymain.cxx ${MOC_SRCS})

If automoc was default to true it would break that code. This mode
gives a finer grain control over the sources, and is more efficient way
to run moc as it will only run moc on the files that need it, and not
run automoc on all files to figure out if it needs to run moc.

-Bill

[Frans Klaver]

I would say it is both speed and backwards compatibility.  Most CMake
  QT4_WRAP_CPP(MOC_SRCS file.h file2.h )
  ADD_EXECUTABLE(mymain.cxx ${MOC_SRCS})
If automoc was default to true it would break that code.  This mode
gives a finer grain control over the sources, and is more efficient way
to run moc as it will only run moc on the files that need it, and not
run automoc on all files to figure out if it needs to run moc.

Great. Thanks for the heads-up.

[Frans Klaver]

Post by Thiago Macieira

Post by Stephen Kelly
Qt on CMake is very very unlikely. Don't expect it to ever happen (though I
of course wish it would).

Qt on qmake is unbearable as a long-term solution.

I'm actually impressed you guys got this far with qmake :).

[Thiago Macieira]

Post by Oswald Buddenhagen

Post by Thiago Macieira
But if someone did the work and proved it to work, we probably
wouldn't say no.

actually, we would. we did before: a complete cmake "port" of qt creator
was offered, and rejected.

I beg to differ. Between cmake and 6 more years of qmake, I'll take cmake and
many people would.

The only reasons to reject cmake indefinitely are if there's something better
to use or if it would seriously set us back in terms of features/support.
Right now there's no such thing new system and you've just claimed that a
research on a buildsystem is just rumour. And cmake devs have offered to make
sure all features we need are supported.

I agree with Lars we shouldn't rush things. But maintaining qmake and the
configure script is unbearable. We *need* a new buildsystem soon. If nothing
else steps up to the plate, that will be cmake.

Personally, I don't like the CMake language and I think throwing in JSON
wouldn't make it much better (I was there in 2004 in Málaga when KDE decided
to use SCons because the language was ugly). But I'll put up with them if
that's what it takes to get us through 2015, as I and many others have since
KDE switched from scons to cmake in 2005.


Just take a look at the discussion yesterday in #qt-labs about running qdoc
before installing Qt. It would have been a non-issue in CMake because it
already supports such a thing and handles RPATH correctly. With the
qmake/configure duo, it's difficult, so we ended up working out several
workarounds until we found one that pisses off the least amount of people. And
then when it came to implementing it, everyone said they were busy.

[Frans Klaver]

On Tue, Oct 4, 2011 at 2:45 PM, Oswald Buddenhagen

Post by Oswald Buddenhagen
this is actually still true. everyone in qtdf who actually has something
to do with build systems has a strong dislike for cmake. the reasons are
widely documented in blog posts and numerous mails on this list.

Ah well, I have a strong dislike for windows programming, but that
doesn't mean I don't (have to) do it. As long as there isn't going to
be any serious follow-up on the blog posts Marius S-O posted in
October 2009 (it's two years since...), people are going to suggest
alternatives to qmake. It's going to be primarily cmake because that,
although arguably mediocre, is the most feature complete, while
staying somewhat predictable, thing out there. If cmake is already
considered mediocre at best, where does that leave the alternatives?

It doesn't really feel, let's say, open to leave everyone guessing
what is going on and what we can expect from a future build system for
Qt.

Post by Oswald Buddenhagen

Post by Stephen Kelly
We will use the buildsystem we're working on as a research project instead".

rumors. ;)

Rumors can be true. The fact that you put a wink smiley there suggests it is :P.