Fixed build error: AddressInputWidget.h is never moc'ed but the moc file is included during build

[jahorta]

I encountered a build error from a fresh clone of the repository. AddressInputWidget.h is never moc'ed but the compiler is instructed to load moc_AddressInputWidget.h. When I moc AddressInputWidget.h it gives a response that nothing was moc'ed from that file, so I commented out the include for moc_AddressInputWidget.h

[cristian64]

This was me blindly adding the file to the MSVC project file without noticing that the class does not specify the Q_OBJECT macro; it doesn't use signals or other meta-object features, so the macro is not technically needed.

I think the potential solutions are:

1. Remove the line from the project file (not only comment it out, but remove it).
2. Introduce the Q_OBJECT macro in the class, even if it's not technically needed right now.
3. Definitely drop the legacy MSVC project files to encourage devs to use the CMake-based project file, which is the file in use in the CI from where releases are made.

There is some discussion in #89 on this topic.

I guess my question is, doesn't the CMake file work well with Visual Studio on Windows? Is there any limitation or issue?

[jahorta]

I don't know a lot about CMake, so I might be doing something wrong, but when I try to use the CMakeLists.txt in the Source folder, I get an error:

1> [CMake] CMake Error at C:\Users\jahor\Source\Repos\jahorta\Dolphin-memory-engine\Source\CMakeLists.txt:51 (find_package):
1> [CMake]   By not providing "FindQt6Widgets.cmake" in CMAKE_MODULE_PATH this project
1> [CMake]   has asked CMake to find a package configuration file provided by
1> [CMake]   "Qt6Widgets", but CMake did not find one.
1> [CMake] 
1> [CMake]   Could not find a package configuration file provided by "Qt6Widgets" with
1> [CMake]   any of the following names:
1> [CMake] 
1> [CMake]     Qt6WidgetsConfig.cmake
1> [CMake]     qt6widgets-config.cmake
1> [CMake] 
1> [CMake]   Add the installation prefix of "Qt6Widgets" to CMAKE_PREFIX_PATH or set
1> [CMake]   "Qt6Widgets_DIR" to a directory containing one of the above files.  If
1> [CMake]   "Qt6Widgets" provides a separate development package or SDK, be sure it has
1> [CMake]   been installed.
1> [CMake] 
1> [CMake] 
1> [CMake] -- Configuring incomplete, errors occurred!

This is using Visual Studio 2022 (64-bit) Version 17.10.3.

[cristian64]

The path to the Qt library needs to be included in CMAKE_PREFIX_PATH. In the command line, it would be something like "-DCMAKE_PREFIX_PATH=..\Externals\Qt\Qt6.5.3\x64", but I can't help much with Visual Studio.

The Qt library for Windows is available in a Git submodule, which I guess you have checked out, or else you would have had problems with the MSVC project too.

[jahorta]

Okay, I was able to add that prefix path in the CMakeLists.txt when building for WIN32. It builds normally with CMake now with Visual Studio on Windows. Should I add that commit here?

[cristian64]

I'm not sure about it. In principle, one should be to configure the project to use their own Qt library or version; simply hardcoding the path may not be the correct thing to do.

[dreamsyntax]

We are talking windows. We ship a specific submodule. It is reasonable to hard code to use the provided submodule.

Why does the dolphin project not drop vcproj?
I'm less inclined to drop it because they don't.

[cristian64]

We are talking windows. We ship a specific submodule. It is reasonable to hard code to use the provided submodule.

Normally we'd check first whether Qt can be found; if not, the path to the Externals is added for a second attempt.

Why does the dolphin project not drop vcproj? I'm less inclined to drop it because they don't.

Good question. With regards to the issue in question, we can simple remove the line for AddressInputWidget and discuss it at any other time.

[jahorta]

Normally we'd check first whether Qt can be found; if not, the path to the Externals is added for a second attempt.

I figured out how to make it first check whether Qt is already installed and revert to Externals for a second attempt for windows only using an if else block and it builds fine on Visual Studio, so I could add that commit instead.

[dreamsyntax]

Normally we'd check first whether Qt can be found; if not, the path to the Externals is added for a second attempt.

Is this typical in C++ projects? I'm fine with it if yes. It seems a bit strange to me, since I could potentially build with an unintended Qt version locally without realizing it if I installed Qt for other projects.

[cristian64]

I figured out how to make it first check whether Qt is already installed and revert to Externals for a second attempt for windows only using an if else block and it builds fine on Visual Studio, so I could add that commit instead.

I think we are after two distinct PRs here.

• One PR (this one) to fix the MSVC project
• One PR to improve the CMake file so that it can find the external Qt

[cristian64]

Is this typical in C++ projects? I'm fine with it if yes. It seems a bit strange to me, since I could potentially build with an unintended Qt version locally without realizing it if I installed Qt for other projects.

For example, in Dolphin, although it provides many external libraries, it usually tries to use the system's (or whatever is defined in the environment) first. Only when they cannot be found does it fallback to using the external libraries. It adds some information messages during the configuration step, announcing the use of the external library when one could not be found. (At least this is the case on Linux.)

[jahorta]

Okay, for this PR I removed the line for loading moc_AddressInputWidget from the project file.