Commit Graph

7 Commits

Author SHA1 Message Date
Igor Korsukov e173d46bd0 renamed some cmake project options 2023-02-14 15:51:40 +02:00
Joachim Schmitz 1100702036 Switch to using Visual Studio 2022 2022-10-29 14:12:45 +02:00
Joachim Schmitz 4a7019792f Switch to Microsoft Visual Studio 2019
for AppVeyor and builds using CMakeSettings.json
2020-04-14 21:55:16 +02:00
J. Edward Sanchez a0a9298ca5 Fix #303483: CMake creates Microsoft Visual Studio projects with incorrect settings
The “CMakeLists.txt” CMake configuration file for MuseScore applies the following default settings to generated Microsoft Visual Studio projects:

1. Force the “install” and “package” targets not to depend on the “all” target.

2. Set the startup project to “mscore”.

These settings are fine. However, the second setting was applied using incorrect syntax, causing the startup project to end up not getting set at all. (It's possible that this syntax used to work in previous versions of Visual Studio, but it doesn't work in either Visual Studio 2017 or Visual Studio 2019). This is now fixed.

Additionally, the following settings are now applied:

3. Set “Debugging” | “Command” to the full path of the built executable installed by the “INSTALL” project.

4. Set “Debugging” | “Command Arguments” to “--debug” so that MuseScore is run in debug mode while being debugged. (Note: This setting requires CMake 3.13.0 or later, so it won't work in Visual Studio 2017, which comes with CMake 3.12.x.)

5. Set “Debugging” | “Working Directory” to the full path of the location of the built executable installed by the “INSTALL” project.

Prior to this fix, the developer had to manually apply the above settings each and every time the Visual Studio projects were generated or regenerated by CMake. Otherwise, any attempt to debug failed with a series of very confusing error messages (e.g., “MuseScore3.exe - Entry Point Not Found: The procedure entry point ?isNCName@QXmlUtils@@SA_NAEBVQString@@@Z could not be located in the dynamic link library C:\Qt\5.9.9\msvc2017_64\bin\Qt5XmlPatterns.dll.”).

These problems are now fixed, making it possible to start debugging MuseScore in Visual Studio immediately after building.

Finally, in the “CMakeSettings.json” schema file, the “buildCommandArgs” property of the “x64-RelWithDebInfo” configuration was set to “-v”. This is a setting for the Ninja generator, but the schema isn't set up for that generator. Instead, it specifies the “Visual Studio 15 2017 Win64” generator, which uses the Microsoft Build Engine (MSBuild). Consequently, building inside Visual Studio using the “CMake” | “Build All” command failed with the following error message: “error MSB1016: Specify the verbosity level.”

In Ninja, the “-v” option is used to show all command lines while building. Since MSBuild already shows the command lines by default, the incorrect “-v” setting has simply been removed.
2020-04-06 13:04:30 -07:00
anatoly-os f90018b857 Support 64-bit compilation
Update cmake files to support 64-bit compilation.
Add variables to easily switch between 32-bit and 64-bit compilation
Update msvc_build.bat to support both 32-bit and 64-bit compilation
Optimize msvc_build.bat to avoi excessive output
Update AppVeyor build scripts so that default compilation is 64-bit now
Make default configuration built from opening MuseScore directory 64-bit
RelWithDebInfo. All other configurations are up to msvc_build.bat
script.
Qt libs which are used for building are placed in msvc2017_64 folder.

These changes require new structure of the dependencies folder.
2018-08-23 10:48:56 +02:00
alexandr df114f189c Compile under MSVC: this commit caontais all changes to run MSVC build
1) fix some bugs which appear in runtime:  replace QString::tostdstring() to Foo.toUtf8().constData().

2) Enable start center online community. To use it you need download webengine in your QT lib. see instruction https://musescore.org/en/handbook/developers-handbook/compilation/compile-instructions-windows-visual-studio-2017-wip

3) update install steps. Add additional dlls for webEngine. Add copying dlls and musescore.exe to /msvc.install/bin folder. Run project will work with the "$(ProjectDir)\..\..\msvc.install\bin\MuseScore.exe" specified in Debugging field in mscore project

4) Moving AppVeyor from MinGW to MSVC. Exclude ALL MSVC project from INSTALL project. Exclude ALL from PACKAGE. Remove migw-cmake in script build, add .bat instead. Remove xcopy from 7z archive step

5) Fix warning : Warning C4703 potentially uninitialized local pointer variable '' used; Warning C4456 declaration of '' hides previous local declaration; Warning C4458 declaration of '' hides class member

6) Change path to 11 version wix toolset which created .msi installer package
2018-08-04 12:17:31 +02:00
Andres Fernandez de Prado 188386ba2e This commit contains all the changes to the CMake build system required to generate a valid Visual Studio 2017 solution and projects for MuseScore.
In detail, changes are as follows:
- Changed .gitignore to ignore VS-specific files and directories.
- VS uses a global settings file for the CMake build process: CMakeSettings.json. This is a text file, which is conceptually equivalent to the Makefile used to invoke CMake through Make. This file might need to be changed on an individual user basis, if dependencies are not installed in default paths.
- New cmake macros to copy files in build\CopyFilesMacros.cmake. The code is from https://cmake.org/pipermail/cmake/2009-March/027892.html
- Pre-compiled headers: Visual Studio requires to create pre-compiled headers per-project (a general per-solution PCH file, although possible, is extremely problematic and not recommended). Therefore, the  new macro vstudio_pch in CreatePrecompiledHeader.cmake was created to add the pre-compiled header creation step to an existing target (similar to what is done for XCode). The existing macro precompiled_header was modified to set the values for a group of variables. As part of this, the empty file all.cpp was added to the root of the source tree, as VS requires a source file to create pre-compiled headers (the header file alone can not be compiled).
- all.h is not copied to binary dir for MSVC, as I could determine no need to do this. Because of this, and the differences in PCH handling, the pseudo-targets mops1 and mops2 are not created for MSVC.
- Revised all steps conditional on toolchain, and added MSVC paths as needed. In many instances, the MSVC path is the same as the MINGW path, but not always.
- The manual (genManual) target used the getopt() functionality defined in POSIX libraries, which is not available on Windows. An LGPL'd port of getopt() for Windows was added in manual\getopt. The original source is in GitHub: nanoporetech/getopt-win32, based on a CodeProject article: https://www.codeproject.com/KB/cpp/getopt4win.aspx?msg=3987371. The corresponding CMakeLists.txt file was modified to include this files when compiling with MSVC.
- Changes in CMakeLists.txt files to create valid MSVC targets. The changes, always conditional on the MSVC toolchain, consist of:
     x Setting target properties for MSVC
     x Using all.h in source dir
     x Adding pre-compiled headers to target
     x Removing dependency from mops1 and mops2

Notes:
- The INSTALL target has NOT BEEN UPDATED for MSVC.
2018-08-03 09:15:42 +02:00