Debian Packaging for JUCE

Linux
1

Hi! I am preparing to package the refactored version of JUCE (coming soon) for Debian and Ubuntu, and have a few questions about the best way to approach this. Typically, a library on Linux is packaged and distributed as a shared object and a set of header files. A typical use might be for a user to install a package named “libjuce-dev”, and that package would install the shared object to /usr/lib/libjuce.so, and the include files to /user/include/*.h, etc… The source code is not typically installed by default on the user’s machine. However, it seems that JUCE is not designed to be used as a shared object, but rather as a code repository that gets copied and compiled into a target application.

Boost Packaging:
If we take a look at how Boost is packaged in Debian, a similar type of library: http://packages.debian.org/source/sid/boost-defaults, it is setup as 18 different shared objects. If an application only needed to link to the boost random functions, it might only depend on libboost-random-dev, one of the shared objects.

Problem #1: IntroJucer
IntroJucer requires the JUCE source code to be available, so it can determine which modules are installed, and so it knows where these files are located, to correctly create the JuceLibraryCode folder and headers. This presents a problem (I think), as most Debian libraries don’t install the source code by default… since usually only the shared object and headers are used by target applications.

Problem #2: Shared Object
If JUCE is installed as a shared object, or a set of shared objects, none of the macros could be changed by target applications, as the library is already compiled. IntroJucer would not work with the newly installed shared objects. However, new applications (that only need to link to JUCE and include a few headers) would work fine with this approach.

Solution?
One solution is to package JUCE so it creates the following binaries: IntroJucer, TheJucer, JuceDemo. These binaries would work, but not use any of the “packaged” shared objects. A set of shared objects would also be generated, with the default macros, and would only be useful for applications that do not use IntroJucer, etc… For example, libjuce-core.so, libjuce-audio-basics.so, juce-events.so, etc… Finally, the source code of JUCE would be installed to some common folder, if IntroJucer is installed, so it would work correctly, assuming the user knew where the source code was installed.

Does this solution seem reasonable? Am i missing anything obvious with this approach? Please let me know what you think. =)

FYI: Previous topics on the JUCE forums related to Debian packaging:
DEB Packages: http://www.rawmaterialsoftware.com/viewtopic.php?f=5&t=7334
Missing install rule and shared library: http://www.rawmaterialsoftware.com/viewtopic.php?f=5&t=2343

Thanks!
-Jonathan

2

hey there, I have packaged JUCE into the KXStudio-Team PPAs, so I know a few tricks you can use.

I would suggest using something like this:

– libjuce1
Contains the shared library in /usr/lib (or adapted to multiarch), so files would be:
/usr/lib/libjuce.so.1 -> /usr/lib/libjuce.so.1.53
/usr/lib/libjuce.so.1.53

– libjuce-dev
Contains the main *.so file, static library, and headers. like this:
/usr/lib/libjuce.a
/usr/lib/libjuce.so -> /usr/lib/libjuce.so.1
/usr/include/juce/juce.h
(…)

– juce-source
Contains the full juce source code, in same place as libjuce-dev
/usr/include/juce/application/
(…)

– juce-demos
Contains the juce demo apps (hello world and juce_demo).

– juce-tools
Contains the misc juce tools (binarybuilder, etc).

– introjucer
Contains the introjucer app.

The dependency could be like any other package, just that introjucer would depend on libjuce-dev and juce-source

Maybe a juce-amalgamated package too perhaps? But Jules is about to cut them off anyway…

Just sharing my opinion

3

Thanks for the suggestions! I’ll be sure to take a peak at your PPA’s packaging before I begin. Also, it really seems like each module should be it’s own binary / shared object, with dependencies between the various related modules:

[list]
[]libjuce_core[/]
[]libjuce_audio_basics[/]
[]libjuce_audio_devices[/]
[]libjuce_audio_formats[/]
[]libjuce_browser_plugin[/]
[]libjuce_opengl[/]
[]etc…[/][/list]
For example, if an application only needs to use the audio libraries in JUCE, it can depend on just those, and not the entire JUCE library as a single shared object. I’m not sure how realistic this approach is, but it makes the most sense in my head. =) Any thoughts on if splitting the modules into their own SO files would work correctly?

Thanks!
-Jonathan

4

[quote=“jonoomph”]Thanks for the suggestions! I’ll be sure to take a peak at your PPA’s packaging before I begin. Also, it really seems like each module should be it’s own binary / shared object, with dependencies between the various related modules:

[list]
[]libjuce_core[/]
[]libjuce_audio_basics[/]
[]libjuce_audio_devices[/]
[]libjuce_audio_formats[/]
[]libjuce_browser_plugin[/]
[]libjuce_opengl[/]
[]etc…[/][/list]
For example, if an application only needs to use the audio libraries in JUCE, it can depend on just those, and not the entire JUCE library as a single shared object. I’m not sure how realistic this approach is, but it makes the most sense in my head. =) Any thoughts on if splitting the modules into their own SO files would work correctly?

Thanks!
-Jonathan[/quote]

You should checkout the latest Git code (modules branch). Jules is doing precisely that - splitting the code into modules.

A sad thing will be no support for building VSTs, although my LV2 wrapper is shaping up nicely (I had a little help…).

EDIT: I must add that I don’t use the default juce makefiles. Instead I use premake (v3.7).
here’s an example -> http://distrho.git.sourceforge.net/git/gitweb.cgi?p=distrho/distrho;a=tree;f=libs/juce-153/standalone;h=d6969a635b8b2216362621f05a2105827502c600;hb=refs/heads/master
(you may wanna checkout that repo once juce gets into debian, it’s full of juce based plugins :wink: )

5

Yes, this is the version I’m currently looking at… The git “modules” branch. I just wasn’t sure if the module folders could be cleanly compiled into their own shared objects, or if this would get messy. But, as you said, if the intention of each module is to compile by itself, then this should work, assuming I can get all the dependencies linked correctly between the modules.

Also, that is very exciting news about the LV2 wrapper! Nice job.

-Jonathan