Я разрабатываю большой проект с использованием Qt 4.6, CMake 2.8 и Visual Studio 2008 для платформы Windows.
Что касается системы сборки, то это все стандартные вещи: я использую макрос CMake QT4_WRAP_CPP для генерации moc-файлов из заголовочных файлов, которые затем связываются с конечным исполняемым файлом в команде add_executable. Все работает как положено.
Единственное ограничение в этой настройке состоит в том, что я не могу определять виджеты или помощника, используя Q_OBJECT в .cpp файлах. Это было бы очень удобно для небольших, зависимых от контекста классов помощников, которые должны появляться рядом с местом их использования.
Я пытался передать весь список исходных файлов (как .h и .cpp ) в QT4_WRAP_CPP, а не только в заголовочных файлах, но это не так работать (не удается связать, потому что некоторые символы, связанные с moc, не определены).
Думаю, проблема в том, что для данной пары файлов foo.h и foo.cpp макрос QT4_WRAP_CPP сгенерирует тот же файл moc ( moc_foo.cxx ) в том же каталоге, и, очевидно, это означает, что первый файл будет перезаписан вторым, и в результате символы будут отсутствовать во время соединения.
Есть ли способ исправить или обойти эту проблему? Например, я попытался добавить определенное правило для foo.cpp вида
QT4_GENERATE_MOC(directory/foo.cpp directory/foo.moc)
и затем добавьте
#include "foo.moc"
в конце foo.cpp . Я думаю, что это должно работать, но, увы, Visual Studio допускает только одно правило сборки на файл, а файлы .cpp уже имеют правило сборки (компиляция в объектный файл), поэтому этот подход не работает, на хотя бы с Visual Studio.
Другая идея, которая у меня возникла, состояла в том, чтобы создать новый макрос, скажем QT4_WRAP_CPP_WITH_PREFIX, на основе QT4_WRAP_CPP (который определен в share / cmake-2.8 / Modules / Qt4Macros.cmake ), что примет дополнительный префиксный аргумент и добавит этот префикс к сгенерированным файлам moc. Таким образом, я бы назвал QT4_WRAP_CPP_WITH_PREFIX дважды, один раз для .h файлов и один раз для .cpp файлов с разными префиксами. Что мне просто не нравится в этом подходе, так это то, что я бы не стал использовать общедоступный API-интерфейс для поддержки Qt внутри CMake.
Есть идея получше?
Cheerz, Franz