Precompiled header support in MOC

  • This is more of a feature request, but I'm not sure where to post it. I have been using Qt for a while, but for large projects it would be really useful to have the option to force the moc to add a specific #include before the automatic one, primarily to support the use of precompiled headers (often, but not always stdafx.h) with MSVC. This can greatly improve compile times.

    Something like the option "-b<file>" which adds #include <file> before the regular include would be most useful. I've seen patches for moc on the web which almost do this, but it would be better if it was supported in the core version.

    Does anyone know if this kind of feature is coming?
    Thanks, John

  • Moderators

    You could search/make a suggestion on the "bug tracker":

    If you just post it here the chances to get it in the sources are negligible.

    If you add it to the bug tracker, please add a link to that webpage here and in the description add a link to this post. Using the link other devnet visitors can vote for your suggestion if they like it.

  • Moderators

    I don't know. But you might post this message on Qt5's mailing list . You can either gather a team with which to implement it, or nudge others to do it for you and the rest of us :)

  • AFAIK, this is already implemented using:
    -f[<file>] force #include, optional file name\n"

    EDIT: never mind, looks like that remove the normal include files.

  • I've had a look at it and it's actually really easy to implement. I can open a merge request with the changes (won't get to it until Sunday though).

  • I've not looked in detail but does it not work if you just use the PRECOMPILED_HEADER variable in your .pro file as described "here":

  • Thanks for the replies. I created a bug report under the category "suggestion" : .

    I have found the /FI compile option for the c compiler which I think I can use instead. ( ).

    I have been using cmake rather than qmake so far, so the PRECOMPILED_HEADER variable was not an option.

  • If using vs2010, the pre compiled headers switch is pretty much obsolete imo. I find the /MP much more usefull in compiling huge projects, which is incompatible with the /Yu switch.

  • I have created a "merge request": for this feature

  • steno : To me the pch is not obsolete. I think it depends greatly on the project type, and it is important to benchmark. I use /MP and /Yu together - I think it is only the pch generation (/Yc) that is not compatible with /MP. The combination gives faster compile times on my projects than either on its own, the pch giving 50% reduction in time and the MP another 20%.

    I prefer not to use /FI as it implicitly adds an include you cannot see in the source code, which can have unexpected consequences.

    loladiro : thanks for the merge request.

  • So what do you do, have another propject create the pre-compiled header and just use it with another project using the /MP switch?

  • I use /MP for the whole project, it seems that /Yc overrides it for the one file that generates the pch. I'm actually using a cmake macro, which also sets the dependency of the pch-users on the pch binary. VS may do this automatically if you manually setup the project, I'm not sure.

  • I actually hacked the Cmake-Script to include StdAfx.h for me. First test seems to work.


    PATCHED QT4_WRAP_CPP for use with StdAfx

    Original source: Qt4Macros.cmake

    MACRO (PCH_QT4_WRAP_CPP outfiles )

    get include dirs

    QT4_EXTRACT_OPTIONS(moc_files moc_options ${ARGN})

    FOREACH (it ${moc_files})
    QT4_MAKE_OUTPUT_FILE(${it} moc_ cxx outfile)
    set (moc_flags_append "-fStdAfx.h" "-f${it}") # StdAfx hack.

    message (STATUS "Moc Flags append ${moc_flags_append}")

    QT4_CREATE_MOC_COMMAND(${it} ${outfile} "${moc_flags};${moc_flags_append}" "${moc_options}")
    SET(${outfiles} ${${outfiles}} ${outfile})

  • Starting with Qt5, the moc will now support the -b<file> option to add optional includes.

  • great.

Log in to reply

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.