Compile in Qt Creator - musescore/MuseScore GitHub Wiki

Summary

  1. Prerequisites
  2. Change default settings
    1. Build folder
    2. Install folder
  3. Open the project
    1. Configure the project
    2. View the source tree
  4. Change project settings
    1. Build settings
    2. Deploy settings
    3. Run settings
  5. Start debugging
    1. Compile
    2. Debug
  6. Common issues
    1. macOS asks "MuseScore would like to access files in your Desktop folder" too often

Qt Creator is a cross-platform IDE (integrated development environment) that comes with Qt and is specifically designed for building Qt software.

It's recommended that all developers use Qt Creator to compile MuseScore. Our internal team uses Qt Creator, so you'll find it's better supported than other IDEs.

Note

In this guide, we refer to Qt Creator's main vertical tabs (🏠 Welcome, ☰ Edit, 🖋️ Design, 🪲 Debug, 🔧 Projects) as screens. We refer to other vertical tabs (e.g. in Preferences) as pages. We reserve the word tabs to refer to horizontal tabs anywhere in the UI.

Fun fact

In Qt Creator's official documentation, the main screens are (somewhat confusingly) referred to as modes, and (even worse) the 🖋️ Design screen is often referred to as Qt Widgets Designer (or simply "Qt Designer", which was the name of a formerly separate program that was incoporated into Qt Creator as the 🖋️ Design screen in Qt 4.7 way back in 2011!).

Prerequisites

You should have already completed the required steps in:

  1. Set up developer environment
  2. Install Qt and Qt Creator
  3. Get MuseScore's source code
  4. Install dependencies

If you're a new developer, you should learn how to compile on the command line before you attempt to set up an IDE.

Change default settings

These changes will affect all software projects you build in Qt Creator, not just MuseScore.

Build folder

Why change this?

By default, Qt Creator creates build folders outside the source folder, which isn't very tidy. Instead, we'll ask it to create builds inside the source folder, under a new subdirectory called builds.

To change the default build directory in Qt Creator:

  1. Go to Preferences > 🔨Build & Run.
  2. Open the Default Build Properties tab.
  3. Go to the Default build directory field. It will contain a value like:
    ../build-%{JS:Util.asciify("%{Kit:FileSystemName}-%{BuildConfig:Name}")}
    
  4. Edit the value to be more like:
    builds/%{JS:Util.asciify("%{Kit:FileSystemName}-%{BuildConfig:Name}")}
    
    The exact changes are:
    1. Remove ../ from the beginning.
    2. Change build- to builds/ (i.e. replace the first - with s/).

This creates build directories like builds/Qt_6_10_1_for_macOS-Debug/ to hold all compiled or CMake-generated files.

Tip

If you compile other projects in Qt Creator, consider adding /builds to their .gitignore or your personal ignore file at .git/info/exclude. This will stop the files inside being tracked by Git or searched by ripgrep.

Install folder

Why change this?

During deployment, CMake installs project files to CMAKE_INSTALL_PREFIX, which defaults to /usr/local on Linux and macOS, or C:/Program Files/${PROJECT_NAME} on Windows. However, installing to these locations requires running our CMake scripts with root or Administrator privileges, which isn't safe for developmental code. Also, the installed files will be owned by the root/Admin user, which makes them difficult to remove. Finally, installing all builds to the same central location can clobber other installations, cause conflicts, and leave behind orphaned files. We can avoid all of these problems by installing into the build folder, under a new subdirectory called install. This makes it easy for you to remove all traces of a build from your machine: simply delete the build folder.

To change the default installation directory in Qt Creator:

  1. Go to Preferences > Kits.
  2. In the Kits tab, select one of the available desktop kits.
    • These usually appear under the "Auto-detected" heading. You may only have one.
    • It will look like 🖥️ Desktop Qt <version> <compiler> or 🖥️ Qt <version> for macOS.
  3. At the bottom of the Kits tab, locate CMake Configuration and click Change.
    • This opens the Edit CMake Configuration dialog for your chosen kit.
  4. In this dialog, add a new definition line below the others:
    -DCMAKE_INSTALL_PREFIX:FILEPATH=%{buildDir}/install
    Before it passes this definition to CMake, Qt Creator automatically expands the %{buildDir} parameter into the actual build folder path, which makes CMake install to folders like builds/Qt_6_10_1_for_macOS-Debug/install/.
  5. Optionally add more lines for other CMake variables you want to define in this dialog:
    -DMUSE_ENABLE_UNIT_TESTS:BOOL=OFF   # Linux & macOS: Keep this ON. Tests are only broken on Windows.
    -DMUSE_MODULE_MUSESAMPLER:BOOL=OFF  # Debugging RelWithDebInfo builds isn't possible with this ON.
    Variables defined here are preserved even if you delete your build directory and start again. Technically, these variables are defined for all projects, not just MuseScore, but the MUSE prefix is there to prevent conflicts.
  6. Repeat steps 2–5 for your other kits, if you have any.
    • If you install another kit in the future, either manually or via Qt's Maintenance Tool, you'll need to repeat these steps for that kit as well.

Note

If you've already configured a project in Qt Creator, you should go to its Build Settings > CMake > Initial Configuration and filter for any variables that you just changed in the kit, such as CMAKE_INSTALL_PREFIX. If all the values are correct, click Re-configure with Initial Parameters. If some are incorrect, manually edit them to the correct value, then click Re-configure with Initial Parameters. Now check the Current Configuration subtab to make sure they are correct there, and parameters like ${buildDir} have been expanded to the values you expect.

Alternative method

Under Initial Configuration, instead of manually editing the incorrect variables, select them and click Unset, then Re-configure with Initial Parameters. This may leave the variables missing or incorrect on the Current Configuration subtab, which is not what we want. If so, return to the Initial Configuration subtab and click Batch edit. Delete the contents of the resulting dialog, then click Re-configure with Initial Parameters again. Now the values should be correct on both subtabs.

Open the project

Inside Qt Creator's 🏠 Welcome screen or File menu, use the option to open an existing project. (Don't use the option to create a new project.)

Open the CMakeLists.txt file in the root of MuseScore's code directory.

Configure the project

You'll be asked to choose a build kit, which means the Qt prebuilt component you installed earlier. It looks like:

  • macOS: 🖥️ Qt <version> for macOS
  • Windows & Linux: 🖥️ Desktop Qt <version> <compiler>

Select a kit and enable at least one configuration type for it, such as:

  • Release with Debug Information (aka RelWithDebInfo). This is the best option for most developers!
  • Debug. This is the best option on very powerful machines, such as Apple Silicon Macs.
About configuration types

The available configuration types (aka build types) are:

Type Description
Debug

Special symbols are included in the compiled executable to enable advanced debugging techniques (e.g. to set breakpoints, pause the running application, step through code line-by-line, monitor the value of code variables, etc.).

Most compiler optimizations are disabled in Debug builds to ensure that control flow in the compiled machine code corresponds very closely to what you wrote in the C++ code. However, this makes the program run more slowly, and a complex app like MuseScore might become unresponsive except on very powerful machines.

Debug is the only configuration type for which the NDEBUG preprocessor macro is NOT defined. As a result, Debug builds behave differently to other build types when code is made conditional via #ifdef NDEBUG, #ifndef NDEBUG, #if defined(NDEBUG), or similar. A key example of this is the assert() statement, and Muse's special IF_ASSERT_FAILED() macro, which intentionally crash Debug builds if the assertion fails. This is good for development purposes because it forces you to fix the faulty logic that led to the failed assertion.

In Qt Creator, QML debugging is enabled by default in Debug builds, which has security implications, but should be safe for development purposes as long as you're behind a firewall. You can disable QML debugging manually if you prefer. C++ debugging is not affected.

Release

All debugging symbols are removed and most compiler optimizations are enabled, which creates a smaller executable that runs faster on end-users' machines. Control flow in the machine code may differ significantly from the C++ code (e.g. more functions may be inlined, and more loops unwound), but the end result should be the same, albeit faster.

The NDEBUG macro is defined in Release builds, so there are no artificial crashes. Instead, failed assert() statements are simply ignored, and Muse's special IF_ASSERT_FAILED() macro just prints a warning on the console and executes the safety code enclosed in the subsequent {} brace block. Other kinds of crash are still possible, of course.

Tip: If you're compiling in Release mode, think carefully before you add any new assert() or IF_ASSERT_FAILED() statements. They won't crash for you, but they might crash for other developers. Filter the app's console output for ASSERT FAILED messages to make sure you haven't missed any.

In Qt Creator, QML debugging is disabled by default in Release builds for better performance and security. You can enable it manually, but MuseScore might crash on launch when this option is enabled outside of a Debug build, so it's best avoided.

RelWithDebInfo

A compromise between Release and Debug. Most Release optimizations are enabled, and most Debug symbols for C++ debugging are included. This facilitates most C++ debugging techniques without unduly sacrificing performance. However, the executable size may still be quite large due to the inclusion of those debug symbols.

The NDEBUG macro is defined in RelWithDebInfo builds, so these builds behave more like Release than Debug, and the same warning about adding new assertions applies.

By default, QML debugging is disabled so only C++ debugging is possible. Again, you can enable QML debugging manually, but MuseScore may crash on launch because this is not a Debug build.

Tip: Use RelWithDebInfo if you find that MuseScore runs slowly when compiled in the Debug configuration, which can occur even on fast machines due to the large size and complexity of the codebase.

Note: Apps with built-in crash reporters are often compiled as RelWithDebInfo to provide meaningful stack traces.

Profile

A special configuration that's unique to Qt Creator. It's like RelWithDebInfo except QML debugging is enabled by default. Unfortunately, MuseScore doesn't appear to launch when this option is used, possibly because the security risks of QML debugging are considered too great outside of Debug builds.

MinSizeRel A release build with further optimizations applied that may sacrifice some performance in return for a smaller executable size.

Since you're a developer using an IDE, it only really makes sense for you to use Debug, Profile, or RelWithDebInfo. If in doubt, choose RelWithDebInfo.

Once you've made a selection, Qt Creator will perform the initial configuration via CMake. You can follow its progress in the General Messages tab at the bottom of the ☰ Edit screen. The initial CMake run takes about 30 seconds to complete.

About the initial CMake run

The initial CMake run is necessary for Qt Creator to understand the project structure in terms of CMake targets (i.e. MuseScore's modules and third-party dependencies), and to show a list of available CMake variables on the Build Settings page. You can't do much in Qt Creator until this run is complete. Once it's complete you can edit CMake variables on the Build Settings page, which requires running CMake again via the button on that page.

What to do if CMake fails on the initial or subsequent runs

If configuration fails, scroll up to find the very first error in the General Messages log. Ignore all subsequent errors because they may just be symptoms of the first error. Fix the first error, then redo the configuration and see if the other errors remain.

If you've edited any CMake files then the failure was probably caused by a problem in those files. Problems in C++ files will not cause errors at this stage.

If you haven't edited any CMake files then a failure here probably means you need to install another dependency or change one of the CMake configuration variables. Instructions change from time to time, so go back and make sure you've properly completed all Prerequisites.

If all else fails, make a note of any CMake variables and values that you have manually edited in Build Settings (if you had gotten that far in this guide) under the Initial Configuration or Current Configuration subtabs, then scroll to the top of the Build Settings page and copy the current configuration's build directory path. Use your file manager or Terminal to delete that build directory:

# Example command to run in MuseScore's source directory:
rm -rf builds/Qt_6_10_1_for_macOS-Debug  # Or whatever your build directory is called.

Now go to the Initial Configuration subtab in Qt Creator. If you had made edits there previously, redo those edits now. Either way, click Re-configure with Initial Parameters. Finally, switch to the Current Configuration subtab and redo any edits you had made there too (not that there should be any).

If the General Messages log indicates that these attempts at configuration also failed, see Development support.

Note

As soon as CMake has finished running, Qt Creator begins analysing the C++ code to build its internal Clang Code Model. While this is happening, you'll see a progress bar in the bottom right of the screen counting the number of files it has analysed so far. This can take a long time to complete, but it's done in the background so you can carry on using the program in the meantime, and even try to compile. When it's finished analysing, it unlocks essential IDE features that you will need to use in order to make any serious contribution.

View the source tree

On the ☰ Edit screen in Qt Creator, go to the tree of files and folders in the left sidebar.

Immediately above the tree should be a dropdown ↕️ containing view options like:

  • Projects (default)
  • Open Documents
  • Bookmarks
  • File System (recommended)
  • ...

Switch to the File System view. This reveals a second dropdown ↕️, which you should change to say MuseScore (i.e. the project name). Now the tree should show all the files and folders in MuseScore's repository.

What's wrong with the Projects view?

In the Projects view, the tree only shows folders that contain a CMakeLists.txt, such as share, src, and vtest. Within those folders, many files are also missing, and many of the "subfolders" aren't really folders, but targets defined in MuseScore's CMake files, or groupings like "Headers" and "Sources" that Qt Creator has decided to lump together. The tree is confusing in this view, so we recommend using the File System view instead as that matches what you see in Git and on GitHub.

Tip

Select a file in the tree and its contents should appear in the editor on the right. See Find your way around the code.

Warning

Don't make any changes to the code yet! Wait until after you've successfully compiled and run the program, otherwise you won't know whether any errors are ours or yours.

Change project settings

After the initial configuration is complete, switch to the 🔧 Projects screen. (This is different to the Projects view mentioned above, which was on the ☰ Edit screen.)

Build settings

On the 🔧 Projects screen, select your kit in the left sidebar and go to:

  • Qt Creator v18+: The Build Settings tab.
  • Older versions: The 🔨 Build page.

Here you should see options to set the current project's:

  • CMake variables
  • Build steps
  • Environment variables

If you followed our earlier recommendation to change the default installation folder then you don't need to do anything here. For now, continue straight to Deploy Settings. You can return to this section later if you need to.

CMake variables you might want to change
CMake variable Recommended value
CMAKE_INSTALL_PREFIX %{buildDir}/install. It should have this value already if you changed the default as recommended earlier.
MUSE_ENABLE_UNIT_TESTS OFF on Windows because the tests are broken there anyway. ON on Linux and macOS so you can run unit tests locally. Set to OFF for a faster initial build, but if the tests fail (or fail to compile) on GitHub Actions, it's hard to debug them remotely.
MUSE_MODULE_MUSESAMPLER OFF unless you need to test with MuseSounds specifically. If so, keep this ON and read the ⚠️ warning in the Debug section.
MUSE_COMPILE_USE_UNITY Keep this ON or the build will likely fail simply because nobody compiles with it OFF, so it rarely gets tested.
About unity buildsUnity builds are faster for the initial build but can be slower for subsequent, incremental builds. Also, IDEs sometimes struggle to understand the code layout of unity builds, although this may be due to configuration problems (i.e. user error). In Qt Creator, if you open a file and see a yellow warning "This file is not part of any project", it may be because of this.

If necessary, use the Filter box above the table to find the variable you need, then double-click on its value to edit it.

You can only use placeholders like %{buildDir} on the Initial Configuration subtab. If you hover over a value, a tooltip appears telling you what the parameter expands to. Or you can switch to the Current Configuration subtab to see the expanded value.

Warning

Changes made under the Initial Configuration or Current Configuration subtabs will be lost the next time you delete your build directory. For this reason, it's best to define all CMake variables at the kit level where possible, as recommended for CMAKE_INSTALL_PREFIX. Notice the Kit Configuration button above the subtabs that avoids having to go through Preferences > Kits.

You should only edit CMake variables at the project configuration level if you have multiple projects/configurations that need to use different values for the same variable. Changes made on the Current Configuration subtab will be lost the next time you press Re-configure with Initial Parameters, so it's better to use the Initial Configuration subtab for this purpose.

Deploy settings

Why is deployment necessary?

By default, Qt Creator compiles the project but doesn't install it, so the resulting program lacks external resources. You'll notice the following problems if you try to run MuseScore in this state:

  • No templates in the New Score dialog's Create from template tab.
  • No braille in the Braille panel.
  • More crashes and failed assertions.

To avoid these problems, it's necessary to install the program.

On the 🔧 Projects screen, select your kit in the left sidebar and go to:

  • Qt Creator v18+: The Deploy Settings tab.
  • Older versions: The ▶ Run page, Deployment section.

Here:

  1. Click Add Deploy Step.
  2. Choose CMake Install.
    • If you don't see CMake Install, choose CMake Build and make sure the install target is selected.

Run settings

On the 🔧 Projects screen, select your kit in the left sidebar and go to:

  • Qt Creator v18+: The Run Settings tab.
  • Older versions: The ▶ Run page, Run section.

Here you should find a dropdown labelled Active run configuration (or just Run configuration). This dropdown contains the names of executable targets declared in the CMake files, such as MuseScoreStudio and (if the unit tests are enabled) braille_tests, engraving_tests, and iex_musicxml_tests, etc.

Tip

Setting the dropdown to one of the tests will cause that test to run instead of MuseScore after you start debugging. This is useful if you've submitted a PR and you're trying to fix the CI checks. You can see the output of the test in the Application Output tab at the bottom of the 🪲 Debug screen.

Naturally, the MuseScoreStudio configuration runs the app itself, but not the deployed version, hence it's necessary to:

  1. Click Add... next to the run configuration dropdown.
  2. Choose Custom Executable and click Create.
  3. Click Rename, enter MuseScore Studio (installed) as the new name, and click OK.
  4. Enter the following in the fields below:
    • Executable:
      • Linux: %{buildDir}/install/bin/mscore
      • macOS: %{buildDir}/install/mscore.app/Contents/MacOS/mscore
      • Windows: %{buildDir}/install/bin/MuseScore4.exe
    • Command line arguments:
      • Leave blank or add any valid arguments. We recommend using -F for development so you always see the program in its initial state. Remove this option if you're working on Preferences and want to check that your changes are persistent.
    • Working directory:
      • %{sourceDir}

In the Environment section:

  1. Click the Details button to the right to see environment variables and their values.
  2. For the Base Environment, choose Build Environment.
  3. If MuseScore compiles successfully but fails to run afterwards, try adding this in the empty box to the right of the variables:
    PATH=+${QTDIR}/bin
    This appears to be necessary if you're building with Qt 6.9+ on Windows.

Start debugging

Compile

To compile the program, click the ▶️🪲 Start debugging button (large green arrow with the small bug symbol) in the bottom left of the screen. While it's compiling, on the ☰ Edit screen, click the Compile Output tab at the bottom to follow the build's progress.

About compilation times

The initial build takes around 10 minutes to complete, but it could be significantly faster or slower depending on your machine. Subsequent, incremental builds are much faster, because it only needs to compile the files that changed, plus any files that #include those files.

MuseScore's modular structure helps to speed up incremental builds by keeping the number of #includes to a minimum, and ensuring that most code changes are confined to each module's internal files, which are not #included in other modules.

What to do if the build fails

If the build fails, scroll up to find the very first error in the Compile Output log. Ignore all subsequent errors because they may just be symptoms of the first error. Fix the first error, then try compiling again and see if the other errors remain.

If you've edited C++ or CMake files then the failure was probably caused by an error in those files. If you haven't edited any files then a failure here probably means you need to install another dependency or change a configuration variable. Instructions change from time to time, so go back and make sure you've properly completed all Prerequisites.

If all else fails, make a note of any CMake variables and values that you have manually edited in Build Settings under the Initial Configuration or Current Configuration subtabs, then scroll to the top of the Build Settings page and copy the current configuration's build directory path. Use your file manager or Terminal to delete that build directory:

# Example command to run in MuseScore's source directory:
rm -rf builds/Qt_6_10_1_for_macOS-Debug  # Or whatever your build directory is called.

Now go to the Initial Configuration subtab in Qt Creator. If you had made edits there previously, redo those edits now. Either way, click Re-configure with Initial Parameters. Finally, switch to the Current Configuration subtab and redo any edits you had made there too (not that there should be any).

Try compiling again. If it still fails, see Development support.

Debug

If the build finishes successfully then MuseScore will launch automatically, and you'll be taken to the 🪲 Debug screen in Qt Creator.

Tip

Now you've done a successful build, you can launch MuseScore more quickly in the future via Qt Creator's Debug (menu) > Start Debugging > Start Debugging Without Deployment. This runs the program immediately without checking if it should be recompiled. Obviously, if you've edited the code you'll need to compile again to see the effects of those changes.

Warning

Debugging is not possible while the MuseSampler library is loaded in MuseScore, and you might have trouble getting MuseScore to quit cleanly.

About MuseSampler and debugging

MuseSampler is a shared library that's loaded dynamically by MuseScore to enable MuseSounds. It's installed in the background by MuseHub when you install at least one MuseSound. It's not provided with any debugging symbols.

You can check whether the library is loaded via MuseScore's Diagnostics menu (or Help > Diagnostics in stable releases, which aren't debuggable anyway) > MuseSampler > Check MuseSampler. If you don't see this option, or if it says MuseSampler wasn't detected, then you're OK to continue debugging.

If MuseSampler is detected, you need to:

  1. Quit MuseScore and MuseHub.
    • If MuseScore won't quit the normal way, use the 🟥 Stop button in Qt Creator, possibly followed by Debug (menu) > Abort Debugging.
  2. Delete or rename the MuseSampler library file (see commands below).
  3. Relaunch MuseScore in Qt Creator.

Note: Next time you open MuseHub, it will silently download MuseSampler again if it's not found at the normal location.

# Linux
cd "${HOME}/.local/share/MuseSampler/lib"
mv libMuseSamplerCoreLib.so libMuseSamplerCoreLib.so.backup
# macOS
cd "${HOME}/Library/Application Support/MuseSampler/lib"
mv libMuseSamplerCoreLib.dylib libMuseSamplerCoreLib.dylib.backup
# Windows - Git Bash
cd "${LOCALAPPDATA}/MuseSampler/lib/"
mv MuseSamplerCoreLib.dll MuseSamplerCoreLib.dll.backup
# Windows - PowerShell
cd "$env:LOCALAPPDATA\MuseSampler\lib\"
mv MuseSamplerCoreLib.dll MuseSamplerCoreLib.dll.backup
: Windows - CMD
cd "%LOCALAPPDATA%\MuseSampler\lib\"
move MuseSamplerCoreLib.dll MuseSamplerCoreLib.dll.backup

Qt Creator's 🪲 Debug screen is similar to the ☰ Edit screen, but there's a new panel below the editor with options for the running application:

  • ⏸️ Interrupt / Continue (i.e. pause/unpause the app)
  • 🟥 Stop (i.e. terminate it)
  • ↪️ Step Over / Step Into / Step Out of code statements line-by-line.

There's also a Locals panel in the top right. To see how this works, click immediately to the left of a line number in the editor to set a 🔴 breakpoint on that line. When the app reaches that line of code, it will pause execution, and the Locals panel should display the values of any variables defined at that point in the code.

Note

The Locals panel can't show values for all variables. Sometimes you have to print the value on the console:

LOGI() << "var is " << var;  // Remember to #include "log.h".

However, this involves recompiling, so it's better to use breakpoints and the Locals panel if you can.

Watch how variables change as you ↪️ Step Over, Step Into, and Step Out of code statements line-by-line. You can also click the Application Output tab at the bottom of the screen to view MuseScore's command line output and debug messages.

Press ⏸️ Continue to unpause the app. If the breakpoint is inside a while or for loop, or a function that gets called repeatedly, the app will pause there again and again until the loop finishes or you click on the 🔴 breakpoint to remove it.

Note

You can't interact with the app while it's paused. On some systems, you might not even be able to see the app window until you unpause it.

Tip

Sometimes it's unclear whether the app is paused, frozen, or properly crashed. The way to tell is via the ⏸️ Interrupt / Continue button in Qt Creator. If the tooltip for this button says "Interrupt" then the app is running but potentially frozen. If the tooltip says "Continue" then you need to actually press the button to find out what state the app is in. If the app was paused then it should now 'unstick' and continue, or it may hit another breakpoint (or the same breakpoint if it's inside a loop). If the app has crashed, you won't be able to unstick it even if you remove all the breakpoints. Instead, the app might terminate as soon as you press the ⏸️ Interrupt / Continue button, or you might have to press 🟥 Stop or even go to Debug (menu) > Abort Debugging.

Common issues

macOS asks "MuseScore would like to access files in your Desktop folder" too often

Every time that you have compiled MuseScore, macOS should ask this one time (one time per folder: Desktop, Documents, Downloads). But on Apple Silicon Macs, the security is a bit more strict; this causes macOS to ask permission again and again, for every single operation MuseScore does with the file system. So, also when loading the list of recent files, macOS will ask it for each recent file again. This is annoying and not workable. The solution is to codesign the compiled MuseScore app. That means running the following command:

codesign --force --deep --sign - /path/to/install/directory/mscore.app

where /path/to/install/directory is the path specified in CMAKE_INSTALL_PREFIX.

In Qt Creator, this can be done too:

  1. Go to Projects mode
  2. Go to "Run"
  3. Under Deployment, click "Add Deploy Step" and then "Custom Process Step"
  4. Enter the following information:
    • Command: codesign
    • Arguments: --force --deep --sign - /path/to/install/directory/mscore.app where /path/to/install/directory is the path specified in CMAKE_INSTALL_PREFIX.
    • (Working directory does not matter.)

If the install directory is /Users/casper/Desktop/MuseScore/MuseScore4_Qt6.install, then the result should look like this:

Setting up the codesign step in Qt Creator
Previous Current
Compile on the command line Top of page
⚠️ **GitHub.com Fallback** ⚠️