I'm porting a Qt project to CMake and after adding set(CMAKE_AUTOUIC ON) I've started experiencing a bunch of compilation problems, which are triggered when trying to compile mocs_compilation.cpp, such as error C2504: 'Lucene::Reader': base class undefined.
After looking into mocs_compilation.cpp, I've found that the file is nothing more than a long list of #include statements bundling source files into a huge translation unit.
CMake's documention mentions the following about mocs_compilation.cpp;
(...)
Not included moc_.cpp files will be generated in custom folders to avoid name collisions and included in a separate <AUTOGEN_BUILD_DIR>/mocs_compilation.cpp file which is compiled into the target.
(...)
With this in mind, how does AUTOMOC determine which files go into mocs_compilation.cpp? And is there any way to keep source files out of mocs_compilation.cpp and build them separately?
Related
I have a project and I need to prepare a CMakeLists.txt file for it.
I also have tests which I need to get an executables for after building the project.
Tests are located in a separate backEndTest folder with their own CMakeLists.txt file.
In order to achieve that I decided to use qtwindeploy tool for that. However, when I compile everything and try to run backEndText.exe file I have errors related to missing dlls.
That's what my main CMakeLists.txt file looks like:
add_subdirectory(backEndTest)
find_package(QT NAMES Qt6 Qt5 REQUIRED COMPONENTS Test)
find_package(Qt${QT_VERSION_MAJOR} REQUIRED COMPONENTS Test)
set(QtBinDir "C:/Qt/6.2.3/mingw_64/bin")
set(winDeploy "${QtBinDir}/windeployqt.exe")
set(backEndTest ${CMAKE_BINARY_DIR}/backEndTest/backEndTest.exe)
set(testBackEnd TRUE)
if (testBackEnd)
execute_process(COMMAND ${winDeploy} ${backEndTest} --compiler-runtime )
endif()
Do you have any idea why dlls are not getting linked?
I have a library called qml_components containing basic QML graphical elements. I'd like to add these files to the project tree, without building them. I've been able to regroup them in a variable, by doing the following:
CMAKE_MINIMUM_REQUIRED(VERSION 3.4)
CMAKE_POLICY(SET CMP0003 NEW)
PROJECT(myApp)
FILE(GLOB QML_SRC "*.qml")
I then tried to add them to my library target:
# Add QML files to project tree without building/compiling them
ADD_CUSTOM_TARGET(myApp ${QML_SRC})
While researching I read that ADD_CUSTOM_TARGET could add the files to the sources without building them:
The SOURCES option specifies additional source files to be included in the custom target. Specified source files will be added to IDE project files for convenience in editing even if they have not build rules.
It doesn't seem to work. I think the probable cause is that I do not generate any binaries from this library, hence the failure when trying to link the sources to the TARGET.
I had forgotten to add the SOURCES keyword in the command...
ADD_CUSTOM_TARGET(myApp SOURCES ${QML_SRC})
I'm leaving this thread open as it could be of useful information to others.
I have been searching about this for a couple of hours but couldn't find a solution, so asking.
I have a solution of projects that includes about 10 projects. But I'm facing a dependency problem. One of my projects generates moc files (QT moc file that was generated by 'QT4_WRAP_CPP' macro of Cmake) and I would like to use this moc file in another project. For now, after running the cmake script and getting the solution, I build all projects and the project that need those moc files generated by previous project complain about linking errors(rightly because I didn't point any file to it in its c-make script in ADD_EXECUTABLE section).
My question is: is there any way to add a 'not built yet but will' file to a project in Cmake to point it meanwhile writing the cmake script?
Here is related section of the cmake script of the project:
//suppose that X projects (which is also in this solution and built before Y project) generates a moc file with the name 'moc_X.cxx'
SET(Y_WORK_STATION_UI_HEADER YWorkStation.h
YSignInWidget.h
YConfigurationWidget.h)
QT4_WRAP_CPP(MOCSrcs ${Y_WORK_STATION_UI_HEADER})
ADD_EXECUTABLE(${PROJECT_NAME}
main.cpp
.
.
.
${MOCSrcs}
%---------------->and here something like moc_X.cxx ?
}
Hope it is clear enough. Thanks in advance.
If the file is generated by something CMake understands (that is, by a custom command in the same CMakeList), you can just list it and CMake will pick up the dependency by itself. For other cases, there is a source file property GENERATED which you can set on the source file to indicate it will be generated during build:
add_executable(${PROJECT_NAME}
main.cpp
.
.
.
${MOCSrcs}
moc_X.cxx ?
)
set_property(SOURCE moc_X.cxx PROPERTY GENERATED TRUE)
You seem to be doing several wrong things.
To start:
What do you mean by 'another project'? Do you actually mean 'another target'?
Why is one project using the moc files of another project? Is it also using the source files of that project? Why?
Why don't you use a static (or other) library if that's your goal? If using the source files of the other project makes sense for some reason (I imagine creating a unit test), then you should probably re-moc the files instead of trying to grab them from another implementation-detail location.
I'm trying to subclass from ProjectExplorer::ProjectExplorerPlugin but I'm getting error telling me about undefined references. Any ideas how to fix it?
class MyPluginPlugin : public ProjectExplorer::ProjectExplorerPlugin
{
Q_OBJECT
...
};
error: undefined reference to `imp__ZN15ProjectExplorer21ProjectExplorerPluginC2Ev'
The fact that you don't get a compilation error, but an undefined reference usually means that your project knows where the header files are, but it doesn't know where the library is which contains the already compiled source code.
I've never written a plugin for Qt Creator but I've taken a quick look at its source code structure and I see the following options:
Option A)
There is a projectexplorer.pro file in Qt Creator's source under src/plugins/projectexplorer. You could manually build that project in order to get a ProjectExplorer.lib (plus a .dll or a .a) and then reference this library.Example: Assuming the library would be created in the same directory as its .pro file (I have no idea if it is like that) and you created your plugin withing Qt Creator's source under src/plugins/myplugin, you would define your LIBS variable like this:
LIBS += -L../projectexplorer \
-lProjectExplorer
The first line adds "../projectexplorer" as an additional library directory and the second line adds "ProjectExplorer" as a library to search in any of the defined directories (it automatically adds the OS-specific file extensions like .lib on windows etc).
Obviously if your project or the library is located somewhere else, you need to change the first line accordingly.
Option B)
You could include the source and header files of the projectexplorer directory to your own .pro file using the HEADERS and SOURCES variables. I'm not sure if this wouldn't interfere with any other plugins (including projectexplorer itself) though.
Option C)
There probably is a way to include the projectexplorer.pro file so that you have a master project which first builds the project explorer library and then your own plugin. This would be the safest way to go as it ensures the Project Explorer library is built and up-to-date before your own project is linked against it.
However I have limited experience on this.
If anyone reading this can give a detailed explanation on this option, feel free to edit or provide your own answer.
If you are using Qt Creator built from source coded after April 2013 which includes Commit: #66a3553 - make library and plugin dependencies declarative, then you can simply specify dependencies for your plugin in its .pro file:
# myplugin.pro
QTC_PLUGIN_DEPENDS += \
coreplugin \
projectexplorer
I have a project with some folders which happen to contain source files with the same names.
My source tree looks like this:
project.pro
foo/
conflict.h
conflict.cpp
bar/
conflict.h
conflict.cpp
some.h
other.h
files.h
main.cpp
Per default, qmake generates a Makefile which will produce a build tree like this:
conflict.o
main.o
target
Where conflict.o is the object file resulting for both foo/conflict.cpp and foo/conflict.h.
I can't to change their names because they are generated using an external tool and forcing different file names would imply to change their contents, so this is not an option.
I also don't want to use qmake SUBDIRS template because this would imply that (1) every subdir is built separately as a library and thus very much complicate the overall build process (in my eyes at least) and (2) in the top level directory I can't have any source files. Or am I wrong?
Can't I just tell qmake to write the object files into separate directories within the build directory? So my build tree will look like this:
foo/
conflict.o
bar/
conflict.o
main.o
target
Or are there any other solutions neither requiring to rename the source files nor introducing something complicated like static libraries? I just can't believe that Qt didn't solve this (in my eyes simple) problem for years. (I already hat this problem 4 years ago but could rename the files in that project, while here I can't.)
If it's important: I use Qt 4.8 on both Ubuntu with G++ and Windows with mingw32.
Are you tied to qmake? If not, an alternative could be to use cmake. I just verified your usecase with a simple CMakeLists.txt like
cmake_minimum_required (VERSION 2.6)
project (conflict)
add_executable(conflict foo/conflict.cpp bar/conflict.cpp main.cpp)
which even included a source file in the top level directory (main.cpp). This properly builds the executable - the object files are created in sub directories like
./CMakeFiles/conflict.dir/main.cpp.o
./CMakeFiles/conflict.dir/bar/conflict.cpp.o
./CMakeFiles/conflict.dir/foo/conflict.cpp.o
cmake also includes support for Qt4, to automatically pull in the required include paths and libraries. It might require some effort to migrate from qmake to cmake, but given the requirements you have I would give it a try.