Support for running Development Builds alongside an Official Release on Linux
The standard advice on these forums is: "Please test new features and look for bugs on nightly builds, but you should keep a copy of the official MuseScore release for everyday usage." On Windows and Mac it is possible to follow this advice and run a standard MuseScore release alongside a development version, but this is not the case on Linux. (Or not easily anyway, see Compile Instructions (Ubuntu 14.10))
Results of looking up "musescore" from the Unity Launcher in Ubuntu 14.10:
With only an official MuseScore release installed (v1.3):
DESIRED result with a nightly build installed too:
ACTUAL result with a nightly build installed.
Note: Clicking either icon runs the nightly build! It is not possible to run the official release (without effort)!
The solution is very simple, BUT potentially catastrophic if people are not made aware of it!
The solution is very simple, BUT potentially catastrophic if people are not made aware of it!
The Linux MuseScore binary excecutable "mscore" and the icon "mscore.png" must be renamed to something like "mscoredev" and "mscoredev.png" (in Development Builds only!!!) to prevent conflicts between Development Builds and Official Releases. These changes must then be reflected in the "mscore.desktop" file:
Contents of "mscore.desktop" file in "musescore/build":
Current version (use this for Official Releases only)
[Desktop Entry] Version=2.0 Comment=WYSIWYG Music score typesetter Comment[ru]=Визуальный редактор нотных партитур Comment[fr]=Gravure de partitions musicales Exec=mscore %F GenericName=Music notation GenericName[de]=Notensatz GenericName[fr]=Notation musicale Icon=mscore Name=MuseScore StartupNotify=true Terminal=false Type=Application Categories=Qt;Audio;Sequencer;Midi;AudioVideoEditing;Music;AudioVideo; MimeType=application/x-musescore;application/x-musescore+xml;application/vnd.recordare.musicxml;application/vnd.recordare.musicxml+xml;
New version (use this for Development Builds only)
[Desktop Entry] Version=2.0 Comment=WYSIWYG Music score typesetter Comment[ru]=Визуальный редактор нотных партитур Comment[fr]=Gravure de partitions musicales Exec=mscoredev %F GenericName=Music notation GenericName[de]=Notensatz GenericName[fr]=Notation musicale Icon=mscoredev Name=MuseScore (development build) StartupNotify=true Terminal=false Type=Application Categories=Qt;Audio;Sequencer;Midi;AudioVideoEditing;Music;AudioVideo; MimeType=application/x-musescore;application/x-musescore+xml;application/vnd.recordare.musicxml;application/vnd.recordare.musicxml+xml;
(Note: It would also be possible to launch the correct version of MuseScore by specifying an absolute file path for the executable in the "mscore.desktop" file, but that method doesn't work for the icon.)
I think that it would be a good idea to look into this ASAP after the release of 2.0. The long delay waiting for 2.0 has got many people interested in MuseScore development that would otherwise just be "users". The entry barrier for development should be lowered as far as possible to sustain the current level of interest after the release of 2.0.
Note: Since these changes only affect Development Builds they are not the job of the Linux package maintainers. However, the package maintainers would need to be made aware that Official Releases must use a different name for the Executable to the Development Builds. This could be accomplished by adding a new build target to the makefile (e.g. "make development" in addition to the existing "make" and "make debug"), but that isn't strictly necessary.
Comments
This issue still exits in 2.0. i.e. Installing a nightly build on Ubuntu renders the official packaged version of 2.0 from the PPA unusable because they are both run by the command "mscore" and both use desktop files called "mscore.desktop" and icons called "mscore.png".
I think the best way to resolve this is...
Change the mscore.desktop file to read:
(changes in bold)
Once the changes are made the package maintainers would need to be notified, but nobody else would be affected.
Result of changes: (under Ubuntu 14.10)
I fixed this myself in a recent PR. The implementation is actually better than the one I proposed above. The Makefile defines the variables SUFFIX and LABEL which can be used to prevent conflicts when multiple versions of MuseScore are installed.
SUFFIX - This is added to the end of filenames to differentiate between versions.
LABEL - This is added to the Launcher icon and title bar to differentiate between versions.
The variables are used as follows when compiling MuseScore:
The program is launched using the command
mscore-self(this avoids conflicts withmscore). It can also be launched by clicking on the relevant Launcher icon, as indicated by LABEL:Note: SUFFIX and LABEL can be set to any values so you can have as many versions of MuseScore installed into
$PATHas you like without conflicts. However, SUFFIX="-nightly" & LABEL="Nightly Build" are reserved for nightly builds and an empty SUFFIX="" & LABEL="" are reserved for official releases of MuseScore.In reply to I fixed this myself in a by shoogle
Thansk for all your work on this!
At some point recently - I assume as a result of your changes - builds stopped working for me on default (building under QtCreator, so via cmake). The install target tried creating a symbolic link in the installation folder, which didn't work because I was installing onto a drive that does not support symbolic links. So I changed the installation folder to another drive, but then the build failed while trying to access a file called "musescore" in the *build* folder. It was apparently expecting this file to be an executable file, an alias for "mscore" I guess. I manually created a symbolic link from mscore to musescore and now I can build again. But it seems I shouldn't have had to do that.
In reply to Thansk for all your work on by Marc Sabatella
No, you shouldn't have had to do that, sorry if I've caused you problems. Out of curiosity, which OS do you use? Your previous posts led me to presume it was Windows but non of my changes affected Windows or Mac (except displaying the version number in the title bar). Perhaps you dual-boot it with a Linux distro (as I do myself).
Anyway, I suspect the problem is that you are building directly with CMake instead of Make, so you are missing out on some important lines in the top-level Makefile. Take a look at the release target, which looks a bit like this:
cd build.release cmake -Dset_various_cmake_options_and_variables="VALUES" make lrelease make manpages make mscore_alias make -j ${CPUS}I added
make manpages,make mscore_aliasand some of the CMake options and variables.If you are calling CMake directly then you need some way to set those options and variables, and then to call the
makecommands. Are you already calling the ones I didn't set through some other means?(One a side note,
make -j ${CPUS}allows Make to execute code in parallel but I don't see how it can have any affect here when it is called last.)In reply to No, you shouldn't have had to by shoogle
I am on Ubuntu 14.04.
I don't call cmake myself, exactly. As I said, I use QtCreator, which does that for me. I have my "Build" rules set up to make lrelease and manpages, my "Deploy" rule set up to make install (works best this way so it doesn't try to make install twice). And I don't use any folder call build.release - I have QtCreator configured to build into ../MuseScore-build
So sounds like maybe you are saying I should add "mscore_alias" to my Build targets?
In reply to I am on Ubuntu 14.04. I don't by Marc Sabatella
Yes, that should solve your problems. It's got me thinking about whether a mixture of Make targets and CMake targets is really the best way to do things though.
Quote: my "Deploy" rule set up to make install (works best this way so it doesn't try to make install twice)
I don't know anything about QtCreator, but it sounds like your Build rule calls CMake (thus skipping the Makefile) but then your Deploy rule calls
make install(thus using the Makefile). However, the first thing that the Makefile install target does is to buildrelease, so it seems that effectively you do end up callingmake releaseafter all, or am I missing something here?Edit: Ah, I think I understand now. You were talking about the install target in the build directory Makefile (
build.release/Makefilefor me,../MuseScore-build/Makefilefor you), not the top-level Makefile.In reply to Yes, that should solve your by shoogle
I have only a fuzzy understanding of how QtCreator, cmake, and make interact, but I understanding is it goes something like this:
- QtCreator calls cmake only when it first does a build in a given folder or sees that something important has changed since the last build. This generally happens only if someone changes something about the build system itself, not on ordinary source code changes
- QtCreator has separate "Build" and "Deploy" steps where the Deploy is optional but most of us use it to force "install" to be made. In theory, the Build step would do "make debug" and the Deploy step "make install", but if you do that, the Deploy step tries to rebuild too, since install depends on debug, and even though it is already built it takes longer than I'd like just to do the necessary checks. At no point to I make release; I think it builds debug (which is what I want) because when I call cmake, I have QtCreator configured to pass in
-DCMAKE_BUILD_TYPE=DEBUG
So no, my build rule does not call cmake. QtCreator runs it only if the build system itself changes, or if I explicitly ask it to.