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.
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.
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