Using custom CMake installation in local directory.

[GPWR]

I thought I'd ask this on the Debian forums since Debian users are generally well acquainted to issues related to obsolete software. Stability is what we get in return for the sacrifice, so this is not a critique at all.

I'm attempting to compile MuseScore 4.0.2 in Debian using CMake. I cloned the Git repo locally to `/var/git/MuseScore/`. Here's the HTTPS link, for those who want to experiment: `https://github.com/musescore/MuseScore.git` I also downloaded the latest CMake binaries from CMake.org/Download, and decompressed them to `/var/git/MuseScore/cmake/`. In other words, there is now a CMake installation within my working directory. The reason I did this is because MuseScore needs a version of CMake which is higher than the one I have installed using the official Debian Bullseye Stable repos, and I'm intending on keeping that version until I upgrade to Debian Bookworm. (I will explain why I'm not upgrading yet later in this post.*)

Now I'm simply wondering how to run `build.cmake` using the CMake installation under `/var/git/MuseScore/cmake/bin/` and not the one under `/usr/bin/`. What files do I need to modify, and what should I add to them?

By the way, I tried cheating and take the "minimum required version" down to 3.15 by modifying the `CMakeLists.txt` and `build.cmake` files, but I ended up concluding that they don't require a minimum version for no reason. xD

Disclaimer: Noob here.

* Reason for not upgrading to Debian Bookworm: I'm not done with school yet. I'll wait until the end of the year, because I can't afford to temporarily break my system until then.

Thank you in advance for any suggestions, and God bless.

P.S. Can't really use VMs. I'm using an Intel Core i2 processor, and running virtual machines normally requires for me to be very cautious. I don't think it'd be ideal for building purposes.

[Random_Troll]

The reason I did this is because MuseScore needs a version of CMake which is higher than the one I have installed using the official Debian Bullseye Stable repo

So use the backported version instead: https://packages.debian.org/bullseye-backports/cmake

https://backports.debian.org/Instructions/

[GPWR]

The reason I did this is because MuseScore needs a version of CMake which is higher than the one I have installed using the official Debian Bullseye Stable repo

So use the backported version instead: https://packages.debian.org/bullseye-backports/cmake

https://backports.debian.org/Instructions/

Thanks for your answer, I appreciate it.

So here's my problem, where the package manager seems to behave as though I have the latest version of CMake, whilst the version information provided by CMake itself does not seem to coincide:

Code: Select all

someone@something:~$ sudo apt-get  install cmake/bullseye-backports
/etc/sudoers:11:70: unexpected line break in string
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbi$
                                                                     ^
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
cmake is already the newest version (3.25.1-1~bpo11+1).
Selected version '3.25.1-1~bpo11+1' (Debian Backports:bullseye-backports [amd64]) for 'cmake'
0 upgraded, 0 newly installed, 0 to remove and 6 not upgraded.
someone@something:~$ cmake --version
cmake version 3.15.2

CMake suite maintained and supported by Kitware (kitware.com/cmake).
someone@something:~$ 

What's funny is that APT shows that 3.25.1 is indeed the latest version available. Strange…

But anyway, won't using a backported version of CMake make my system unstable? I normally try to use software that's been thoroughly tested, except a few exceptions (including MuseScore, of course).

Thanks again, and have a great day.

[Random_Troll]

Show us a full shell session in which you attempt to compile MuseScore. Use the script(1) command to record the session and then share the file here. Thanks.

Also fix /etc/sudoers, looks like it's a bit broken.

Backports are not as tested as the software from the (old)stable repositories but this would also apply to a locally compiled newer version.

[GPWR]

Thank you for your response, and for taking the time to help me out.

Show us a full shell session in which you attempt to compile MuseScore. Use the script(1) command to record the session and then share the file here. Thanks.

Okay, the file is attached below. I recorded a session where I clone the MuseScore repo, download CMake, install the latter within the MuseScore repo directory, and attempt to run `build.cmake` with no success. Do you know how I should modify the CMake instruction within the MuseScore directory to use the CMake install in `./cmake/bin`, and not the systemwide-installed version?

Also fix /etc/sudoers, looks like it's a bit broken.

Done, thanks for the reminder. A double quote had been missing to one of the lines of that file for more than a year, and yet the error was not fatal. Impressive how hard it is to actually break Debian.

Backports are not as tested as the software from the (old)stable repositories but this would also apply to a locally compiled newer version.

Yeah, I'm not planning on using that new version for anything other that MuseScore, or other software that needs it. That's why I'm keeping the good old packaged version of CMake on my system.

God bless you.

Recorded Bash session: link to file (Sorry for the MEGA link, I got an error when trying to attach the file directly to this post, and changing the file extension did not work.)

[Random_Troll]

I recorded a session where I clone the MuseScore repo, download CMake, install the latter within the MuseScore repo directory, and attempt to run `build.cmake` with no success.

Why did you do that? I thought we were going to try to use the backported cmake version, as supplied by the Debian package. Why are you trying to use a locally compiled version? Try it again but use the system-supplied cmake this time.

God bless you.

Unlikely, but thanks for the thought

[GPWR]

Try it again but use the system-supplied cmake this time.

Oh, excuse me for the misunderstanding. Here's another try with the system-supplied CMake: linkToFile

Thanks again, eh!

Off Topic

Unlikely, but thanks for the thought

You're very welcome. I would rather say that it is very likely that He do bless you, especially if one dare ask Him to. I would discretely suggest that you take a look at Matthew 6:26 (the line that start with "Look at the birds in the sky…"). Of course, it is just a humble suggestion. (;

[Random_Troll]

Code: Select all

$ cmake --version
cmake version 3.15.2

Well that's not right

Check

Code: Select all

type cmake

The Debian package installs the executable under /usr/bin/.

Off Topic

I would discretely suggest that you take a look at Matthew 6:26

I looked at that but then I read Psalms 145:20 and I think I might be SOL

[GPWR]

Check

Code: Select all

type cmake

The Debian package installs the executable under /usr/bin/.

Hmm, mine returns `/usr/local/bin`. Does that mean it wasn't installed properly? Is it safe to remove and reinstall completely using the backported version, perhaps?

Off Topic

I looked at that but then I read Psalms 145:20 and I think I might be SOL

It's quite encouraging to see that even the wicked offer to help those who experience computer problems for free and so kindly!

On another note, St Paul used to persecute others "beyond measure" (Galatians 1:13) before he changed his mind, and now the Church recognises him as one of the most influential saints, as well as a source of great knowledge and wisdom even for non-Christians. By the way, he's the patron saint of writers, journalists, authors and public workers, amongst other things. Maybe you can find yourself somewhere in there?

Have a nice one.

[Random_Troll]

Hmm, mine returns `/usr/local/bin`. Does that mean it wasn't installed properly?

That probably indicates that you've run `make install` with the newer version's source code.

Is it safe to remove and reinstall completely using the backported version, perhaps?

If you remove the newer version then the backported cmake should be picked up automatically.

Looks like the cmake tarball includes an uninstall target in the Makefile so change into that source directory and run this command as root:

Code: Select all

make uninstall

Then check `type cmake` again.

Off Topic

Maybe you can find yourself somewhere in there?

I already have a patron saint, as it happens. I am a traveller so I carry a Saint Chistopher with me.

[GPWR]

That probably indicates that you've run `make install` with the newer version's source code.

I'm 99.99999 % sure I've never installed CMake using the source. Just in case I'm having severe memory issues, I tried uninstalling it by downloading the source and running `make uninstall, but there seems to be no uninstall target, as opposed to what you mentioned. Maybe I am not running the proper command... Here's my session:

Code: Select all

someone@something:/var/git$ cd cmake/
someone@something:/var/git/cmake$ ls
Auxiliary         CMakeCPackOptions.cmake.in  CMakeLogo.gif             configure         CTestConfig.cmake     Help      Packaging   Templates
bootstrap         CMakeGraphVizOptions.cmake  cmake_uninstall.cmake.in  CONTRIBUTING.rst  CTestCustom.cmake.in  Licenses  README.rst  Tests
CMakeCPack.cmake  CMakeLists.txt              CompileFlags.cmake        Copyright.txt     DartConfig.cmake      Modules   Source      Utilities
someone@something:/var/git/cmake$ make uninstall
make: *** No rule to make target 'uninstall'.  Stop.
someone@something:/var/git/cmake$ make remove
make: *** No rule to make target 'remove'.  Stop.
someone@something:/var/git/cmake$

If you remove the newer version then the backported cmake should be picked up automatically.

Code: Select all

someone@something:/var/git/cmake$ sudo apt-get remove --purge cmake
[sudo] password for someone:
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
  cmake-data libjsoncpp24 librhash0
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
  cmake*
0 upgraded, 0 newly installed, 1 to remove and 3 not upgraded.
After this operation, 29.9 MB disk space will be freed.
Do you want to continue? [Y/n] 
(Reading database ... 699107 files and directories currently installed.)
Removing cmake (3.25.1-1~bpo11+1) ...
Processing triggers for man-db (2.9.4-2) ...
someone@something:/var/git/cmake$ sudo apt-get autoremove --purge
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
  cmake-data* libjsoncpp24* librhash0*
0 upgraded, 0 newly installed, 3 to remove and 3 not upgraded.
After this operation, 11.2 MB disk space will be freed.
Do you want to continue? [Y/n] 
(Reading database ... 699094 files and directories currently installed.)
Removing cmake-data (3.25.1-1~bpo11+1) ...
Removing libjsoncpp24:amd64 (1.9.4-4) ...
Removing librhash0:amd64 (1.4.1-2) ...
Processing triggers for man-db (2.9.4-2) ...
Processing triggers for libc-bin (2.31-13+deb11u6) ...
(Reading database ... 695858 files and directories currently installed.)
Purging configuration files for cmake-data (3.25.1-1~bpo11+1) ...
someone@something:/var/git/cmake$ sudo apt-get upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
someone@something:/var/git/cmake$

From above you can see that the backported version is what seems to have been removed (although we know that it is not the "real" backported version). Upgrading therefore does not result in the backported version being picked up automatically.

Code: Select all

someone@something:~$ sudo apt-get install -t bullseye-backports cmake
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  cmake-data libjsoncpp24 librhash0
Suggested packages:
  cmake-doc cmake-format elpa-cmake-mode
The following NEW packages will be installed:
  cmake cmake-data libjsoncpp24 librhash0
0 upgraded, 4 newly installed, 0 to remove and 175 not upgraded.
Need to get 0 B/11.0 MB of archives.
After this operation, 41.1 MB of additional disk space will be used.
Do you want to continue? [Y/n] 
Selecting previously unselected package libjsoncpp24:amd64.
(Reading database ... 695858 files and directories currently installed.)
Preparing to unpack .../libjsoncpp24_1.9.4-4_amd64.deb ...
Unpacking libjsoncpp24:amd64 (1.9.4-4) ...
Selecting previously unselected package librhash0:amd64.
Preparing to unpack .../librhash0_1.4.1-2_amd64.deb ...
Unpacking librhash0:amd64 (1.4.1-2) ...
Selecting previously unselected package cmake-data.
Preparing to unpack .../cmake-data_3.25.1-1~bpo11+1_all.deb ...
Unpacking cmake-data (3.25.1-1~bpo11+1) ...
Selecting previously unselected package cmake.
Preparing to unpack .../cmake_3.25.1-1~bpo11+1_amd64.deb ...
Unpacking cmake (3.25.1-1~bpo11+1) ...
Setting up libjsoncpp24:amd64 (1.9.4-4) ...
Setting up librhash0:amd64 (1.4.1-2) ...
Setting up cmake-data (3.25.1-1~bpo11+1) ...
Setting up cmake (3.25.1-1~bpo11+1) ...
Processing triggers for man-db (2.9.4-2) ...
Processing triggers for libc-bin (2.31-13+deb11u6) ...
someone@something:~$ cmake --version
cmake version 3.15.2

CMake suite maintained and supported by Kitware (kitware.com/cmake).
someone@something:~$ type cmake
cmake is hashed (/usr/local/bin/cmake)
someone@something:~$

And, as you can see here, trying to reinstall using backports does not work. However, the system "lies" and indicates that the backported version (3.25.1-1~bpo11+1) is being installed. This is quite strange...

Looking forward to knowing what you think of all this very curious matter, and thanks so much again.

Off Topic

I already have a patron saint, as it happens. I am a traveller so I carry a Saint Chistopher with me.

Very cool! I guess that's also a way of asking God's blessing through the intercession of a saint, isn't it? (; All the best, and good luck on your next journey, wherever that may be.

[Random_Troll]

I tried uninstalling it by downloading the source and running `make uninstall, but there seems to be no uninstall target, as opposed to what you mentioned.

You have to create the Makefile first by running this command in the source directory:

Code: Select all

./configure

But don't try that yet because:

Code: Select all

someone@something:~$ type cmake
cmake is hashed (/usr/local/bin/cmake)
someone@something:~$

If a command is described as "hashed" that means bash has saved the location of the file and hasn't actually looked for it.

So try

Code: Select all

hash -r
type cmake

If that still points to /usr/local/bin/cmake generate the Makefile and use the uninstall target.

Don't worry about APT, it isn't lying to you. I didn't mean for you to use the package manager to remove anything, I was referring to the removal of /usr/local/bin/cmake, sorry if that was unclear. No Debian package will ever place anything in /usr/local/bin/.

[GPWR]

If that still points to /usr/local/bin/cmake generate the Makefile and use the uninstall target.

Thanks so much. Everything works now. I had to install CMake using `sudo make install` and then uninstall it using the uninstall target, because it refused to uninstall without first installing. (Excuse the tongue twister.) However, everything worked in the end, because reinstalling the backported CMake with APT resulted in CMake and APT finally agreeing on the version number (yes!) And now the CMake binary is in `/usr/bin/` as it should. (:

MuseScore is now buildable, thanks!

Still curious as to how to run CMake with a foreign install, (i.e. installed in a local directory with no system links) but I'll keep that for the CMake forums. I think the backports are a nice compromise between stability and newness, so thanks for bringing that up earlier!

Thanks again for your very educative answers and generous help. I learned lots and enjoyed the process. I hope you did too, despite my technical ignorance. Take care.