QT4_WRAP_CPP and Implicit Dependencies

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

QT4_WRAP_CPP and Implicit Dependencies

Miller, Frank
Greetings,

Suppose we have a header file, Dum.h, that is included by another header
file, Main.h, and Main.h needs to be processed with the qt moc tool.
When Dum.h changes, should we rerun moc on Main.h?

QMake says yes. CMake, using QT4_WRAP_CPP, says no.

I am inclined to believe qmake on this one. However, I have yet to think
of a way to break a build by not rerunning moc. Is this a problem?

Please pardon me if you think this question is in the wrong forum. I am
asking here because I know there are a lot of qt users in this community
and qmake is clearly not doing anything wrong.

Here is a simple example:

    === CMakeLists.txt ===
    cmake_minimum_required( VERSION 2.8.0 )
    project( mocdep )
    find_package( Qt4 REQUIRED )
    include( ${QT_USE_FILE} )
    include_directories( ${CMAKE_BINARY_DIR} )
    QT4_WRAP_CPP( mocdep_MOCSOURCES Main.h )
    add_executable( mocdep Main.cpp ${mocdep_MOCSOURCES} Main.h )
    target_link_libraries( mocdep ${QT_QTCORE_LIBRARY} ${QT_QTGUI_LIBRARY} )

    === mocdep.pro ===
    HEADERS = Main.h Dum.h
    SOURCES = Main.cpp

    === Dum.h ===
    #pragma once

    === Main.h ===
    #pragma once
    #include "Dum.h"
    #include <QMainWindow>

    class MainWindow : public QMainWindow
    {
        Q_OBJECT
    };

    === Main.cpp ===
    #include "Main.h"
    #include <QApplication>

    int main( int argc, char * argv[] )
    {
        QApplication app(argc, argv);

        MainWindow mainWindow;
        mainWindow.show();

        return app.exec();
    }

Frank

This communication, including any attachments, may contain information that is proprietary, privileged, confidential or legally exempt from disclosure. If you are not a named addressee, you are hereby notified that you are not authorized to read, print, retain a copy of or disseminate any portion of this communication without the consent of the sender and that doing so may be unlawful. If you have received this communication in error, please immediately notify the sender via return e-mail and delete it from your system.
--

Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: QT4_WRAP_CPP and Implicit Dependencies

Clinton Stimpson
If you run moc on Main.h, which includes Dum.h, moc doesn't even open "Dum.h" to scan its contents.
That tells me there is no way that moc would be required to rescan Main.h if Dum.h is modified.

Clint


On Oct 10, 2012, at 10:32 PM, Miller, Frank wrote:

> Greetings,
>
> Suppose we have a header file, Dum.h, that is included by another header
> file, Main.h, and Main.h needs to be processed with the qt moc tool.
> When Dum.h changes, should we rerun moc on Main.h?
>
> QMake says yes. CMake, using QT4_WRAP_CPP, says no.
>
> I am inclined to believe qmake on this one. However, I have yet to think
> of a way to break a build by not rerunning moc. Is this a problem?
>
> Please pardon me if you think this question is in the wrong forum. I am
> asking here because I know there are a lot of qt users in this community
> and qmake is clearly not doing anything wrong.
>
> Here is a simple example:
>
>    === CMakeLists.txt ===
>    cmake_minimum_required( VERSION 2.8.0 )
>    project( mocdep )
>    find_package( Qt4 REQUIRED )
>    include( ${QT_USE_FILE} )
>    include_directories( ${CMAKE_BINARY_DIR} )
>    QT4_WRAP_CPP( mocdep_MOCSOURCES Main.h )
>    add_executable( mocdep Main.cpp ${mocdep_MOCSOURCES} Main.h )
>    target_link_libraries( mocdep ${QT_QTCORE_LIBRARY} ${QT_QTGUI_LIBRARY} )
>
>    === mocdep.pro ===
>    HEADERS = Main.h Dum.h
>    SOURCES = Main.cpp
>
>    === Dum.h ===
>    #pragma once
>
>    === Main.h ===
>    #pragma once
>    #include "Dum.h"
>    #include <QMainWindow>
>
>    class MainWindow : public QMainWindow
>    {
>        Q_OBJECT
>    };
>
>    === Main.cpp ===
>    #include "Main.h"
>    #include <QApplication>
>
>    int main( int argc, char * argv[] )
>    {
>        QApplication app(argc, argv);
>
>        MainWindow mainWindow;
>        mainWindow.show();
>
>        return app.exec();
>    }
>
> Frank
>
> This communication, including any attachments, may contain information that is proprietary, privileged, confidential or legally exempt from disclosure. If you are not a named addressee, you are hereby notified that you are not authorized to read, print, retain a copy of or disseminate any portion of this communication without the consent of the sender and that doing so may be unlawful. If you have received this communication in error, please immediately notify the sender via return e-mail and delete it from your system.
> --
>
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake

--

Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: QT4_WRAP_CPP and Implicit Dependencies

Andreas Pakulat-2
Hi,

in addition to that, moc does not support ifdef'ing of code it needs
to look at (it does not have a preprocessor at all, only knows a few
select define's), so there can also not be a case of Dum.h setting
defines which cause moc to generate different code for Main.h.

I'd say qmake is just too dumb to be able to differ in this case.

Andreas

On Fri, Oct 12, 2012 at 5:38 PM, Clinton Stimpson <[hidden email]> wrote:

> If you run moc on Main.h, which includes Dum.h, moc doesn't even open "Dum.h" to scan its contents.
> That tells me there is no way that moc would be required to rescan Main.h if Dum.h is modified.
>
> Clint
>
>
> On Oct 10, 2012, at 10:32 PM, Miller, Frank wrote:
>
>> Greetings,
>>
>> Suppose we have a header file, Dum.h, that is included by another header
>> file, Main.h, and Main.h needs to be processed with the qt moc tool.
>> When Dum.h changes, should we rerun moc on Main.h?
>>
>> QMake says yes. CMake, using QT4_WRAP_CPP, says no.
>>
>> I am inclined to believe qmake on this one. However, I have yet to think
>> of a way to break a build by not rerunning moc. Is this a problem?
>>
>> Please pardon me if you think this question is in the wrong forum. I am
>> asking here because I know there are a lot of qt users in this community
>> and qmake is clearly not doing anything wrong.
>>
>> Here is a simple example:
>>
>>    === CMakeLists.txt ===
>>    cmake_minimum_required( VERSION 2.8.0 )
>>    project( mocdep )
>>    find_package( Qt4 REQUIRED )
>>    include( ${QT_USE_FILE} )
>>    include_directories( ${CMAKE_BINARY_DIR} )
>>    QT4_WRAP_CPP( mocdep_MOCSOURCES Main.h )
>>    add_executable( mocdep Main.cpp ${mocdep_MOCSOURCES} Main.h )
>>    target_link_libraries( mocdep ${QT_QTCORE_LIBRARY} ${QT_QTGUI_LIBRARY} )
>>
>>    === mocdep.pro ===
>>    HEADERS = Main.h Dum.h
>>    SOURCES = Main.cpp
>>
>>    === Dum.h ===
>>    #pragma once
>>
>>    === Main.h ===
>>    #pragma once
>>    #include "Dum.h"
>>    #include <QMainWindow>
>>
>>    class MainWindow : public QMainWindow
>>    {
>>        Q_OBJECT
>>    };
>>
>>    === Main.cpp ===
>>    #include "Main.h"
>>    #include <QApplication>
>>
>>    int main( int argc, char * argv[] )
>>    {
>>        QApplication app(argc, argv);
>>
>>        MainWindow mainWindow;
>>        mainWindow.show();
>>
>>        return app.exec();
>>    }
>>
>> Frank
>>
>> This communication, including any attachments, may contain information that is proprietary, privileged, confidential or legally exempt from disclosure. If you are not a named addressee, you are hereby notified that you are not authorized to read, print, retain a copy of or disseminate any portion of this communication without the consent of the sender and that doing so may be unlawful. If you have received this communication in error, please immediately notify the sender via return e-mail and delete it from your system.
>> --
>>
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.cmake.org/mailman/listinfo/cmake
>
> --
>
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
--

Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake