Jump to content

Amarok/Development/Hacking On Amarok HowTo

From KDE Community Wiki

How to become involved

  1. Most discussion regarding Amarok development happens in IRC. Join us in #amarok on irc.freenode.net.
  2. Join the mailing list.
  3. Read everything in the HACKING folder. It goes over the Amarok coding style and other important information.
  4. Submit your patch. There are several channels to do so:
  • Bug Tracker: Search for the problem you are solving on KDE's bugzilla and attach the patch. If there isn't a bug for it yet, create a new bug or wishlist and then attach the patch.
  • IRC: IRC has the advantage that a developer might happen to be online and has the time to test your patch, it could be applied immediately or give immediate feedback.
  • Mailing lists: Things often get overlooked in the mailing list, so do not rely on it. However it is a good method of bringing up a subject with the development team.

How to Hack on Amarok's Codebase Using KDevelop

  • Install the KDevelop IDE (Integrated Development Environment). You should use your distribution's package, or build using Konstruct.
  • Fire up KDevelop and from the "Project" menu, select "Open Project...", then choose the amarok.kdevelop file from the extragear/multimedia/amarok/ directory.
  • Compile Amarok normally once through the standard means.
  • From the "Build" menu select "Build Project" to build Amarok after you have made changes.
  • To find the source of a particular feature, a good method is to find an English string associated with the feature and then search for it via "Edit" → "Find in Files".
  • For more on setting up KDevelop 4, see Setting up KDevelop
    • Note: If anyone knows how to debug Amarok in Kdevelop please add detailed instructions here.

How to Hack on Amarok's Codebase Using Qt Creator

  • Fire up Qt Creator, and from the "File" menu select "Open File or Project".
  • Navigate to the Amarok source directory and select the file CMakeLists.txt
    • NOTE: If Qt Creator opens CMakeLists.txt as a text file and doesn't start the CMake Wizard, you may have to install a separate CMake plugin for QtCreator (the build available in the Ubuntu repositories itemizes it out as 'qtcreator-plugin-cmake').
  • Configure the build directory for QtCreator:
    • The standard place to build is in $HOME/kde/build/amarok as outlined in the Amarok/Development/Development HowTo
    • QtCreator probably won't be configured to build there, to find out, click Projects on the Mode selector (only enabled if you have a project open), and find Build directory under Build Settings > CMake.
    • It will probably follow the pattern defined in QtCreator under Tools > Options > Build & Run > Default build directory
    • You will need to change the Projects Build directory, changing QtCreator's Default build directory will not have an effect.
      • There appears to be a bug in QtCreators Cmake wizard that does not respect the user specified Default build directory
      • Set the Project's to Build directory $HOME/kde/build/amarok
      • QtCreator will probably run cmake again when you change it but to make sure, run it as follows:
        • On the Mode selector click Edit
        • Right-click on the Amarok project (probably listed at top of the project tree as Amarok [master]), then click Run CMake
        • Notice the output under General messages and check the folder $HOME/kde/build/amarok
        • If feeling unsure, just remove the directory $HOME/kde/build/amarok and run CMake again, and you should find it's recreated confirming you have it all configured fine.
  • Configure QtCeator's make parallelism
    • If you have a multicore processor the default build time may be a lot slower than need be. I use an 8 core processor with 32GB RAM and an SSD and a full rebuild was taking 15 mins, but I got that down to 3 mins as follows:
      • In QtCreator, On the Mode selector, click Projects
      • Under Build Settings find Build Steps, and under that find Make.
      • Click Details
      • Under Additional arguments enter -j16 (or if not 16 as many parallel jobs as you'd like make to run, I've just used twice the number of cores I have following some advice but can't really comment on what's optimum here).