[svn trunk] building mscore deb packages
Linux distribution: Ubuntu 9.10
Qt: Qt 4.6.1 installed from debs built locally from the qt4-x11 source package for Lucid http://packages.ubuntu.com/en/source/lucid/qt4-x11
MuseScore svn revision: 2695
I'm well aware of the official compile instructions http://musescore.org/node/3894, but would love to have a more or less straightforward way to build deb packages, because this makes testing much easier. Apparently, changing the prefix in https://mscore.svn.sourceforge.net/svnroot/mscore/trunk/Makefile to "/usr", running
make release
cd build
make package
seems to do the right thing, but the last command in the "preinstall" target attempts to overwrite system libraries
libqtscript_core.so
libqtscript_gui.so
libqtscript_network.so
libqtscript_uitools.so
libqtscript_xml.so
in /usr/lib/qt4/plugins/script/ and to install libawlplugin.so to /usr/lib/qt4/plugins/designer/.
What is the proper way to disable this unwanted behavior? Surely not deleting lines containing e.g. "build/awl/cmake_install.cmake" in build/cmake_install.cmake prior to running "make package" like I do for now, though the compiled mscore binary seems to run fine.
It would be great if there were a single simple command to build a MuseScore package. The "make unix" target in the top-level Makefile promises this, but is broken (it lacks at least a backslash on the line 128).
Comments
I'm far from an expert about packaging linux software. I do the packaging for windows and macosx.
I was at FOSDEM this week end and attend a session about the openSuse build service. The promise of this service is to enable the packaging of a software package on several distributions (debian 4/5, ubuntu since 6.06, fedora, opensuse etc...)
If we manage to have a good packaging process for debian, I guess we can setup an "official" nightly build delivery with this service.
Regarding your specific question, the changes should be made in the CMake CMakeLists.txt somewhere.
More about cmake and debian packaging support
In reply to CMake by [DELETED] 5
Thank you for your prompt reply and the hints. A build service for static builds, able to run on a big variety of older distributions would be nice, but since Qt4.6 will be shipped with Ubuntu 10.04 in three months, compiling locally won't be a hurdle soon.
If I were a developer, of course, I would just submit a patch for a handy deb packaging instead of complaining. Meanwhile, I even managed to elaborate a private "chainsaw massacre" style patch, which makes the "unix" target work without further interaction. Basically, it skips the scriptgen directory (which saves a lot of time) in the top-level CMakeLists.txt and comments out the "install" target in awl/CMakeLists.txt.
What is this libawlplugin.so exactly for? Apparently, /usr/bin/mscore is not linked against libawlplugin.so.
In reply to Thank you for your prompt by Ilja Sekler
Just for the sake of completeness I do attach a more civilized minimal private patch based on the patch in https://bugs.launchpad.net/ubuntu/+source/mscore/+bug/521584 (which doesn't apply cleanly to the trunk anymore) to build MuseScore deb packages with "make unix" command.
Resulting debs get the svn revision number added to the file name and to debian package name.
In reply to Quick & dirty MuseScore debs with CPack by Ilja Sekler
As to http://musescore.org/node/4569#comment-12132 it is unnecessary to clean the build. If one can afford permanently about 1GB HDD space for the MuseScore build directory, the following patch (sorry, it contains some cosmetic changes for the Makefile too) won't protest if the build directory "linux" is not deleted prior to running "make unix".
This reduces MuseScore compilation time for subsequent builds to 7 minutes for me.
In reply to Quick & dirty MuseScore debs with CPack - fast by Ilja Sekler
Generally it is not necessary to delete the build files. However after an upgrade in the build environment (new Qt version, JACK, etc.) you might get errors if you don't start from a clean build.
In reply to Generally it is not necessary by David Bolton
Thank you for clarifying this. Meanwhile, the quick&dirty patch suffered bitrot. An updated version which disables additionally redundant packaging as *.tar.bz2 is attached. If *.tar.bz2 is wanted, delete the hunk #4 for mscore/CMakeLists.txt in the patch.
Update: the target "unix" in the top-level Makefile lacks "make lrelease", which is present in the target "release" and is necessary to generate the corresponding *.qm file if a new language is added to MuseScore (http://musescore.org/node/4737#comment-12560). I attach an updated version of the patch, which applies cleanly to r2789 and includes "make lrelease".