Newbie question about how to manage shared code

I have been reading documentation/tutorials etc.

I need to write a few core "libraries", which I can access in multiple GUI applications.  The apps need to run on Windows, Linux, and Android (and possbily OSX).

Typically i create a shared (or static library)

In Introjuicer when i create a new project, I can create  a Gui or console application, audio plug in, static library, or dynamic library.

I created a static library as a test, and then created a separate Gui project.

Both compile, but i can not figure out how in Introjuicer to reference the library from the Gui project.  searching led me to the "The Juice Module format" on under documentation.

It looks like what i am really supposed to do is create one or more of my own modules.

I have 2 questions:

1) What should i be doing Modules vs static/dynamic libraries.

2) if it is modules, do i have to put them in the same directory as the juice modules to pick them up, or can i somehow tell introjuicer to pick up modules from multiple directories.

3) if it is libraries, how do i reference them from my GUI introjuicer project?




I don't think there is a single correct solution for this.  So I'll tell you how I've done it. 

I run git.  I have a git submodule in each project for my shared library.  It has git submodules for JUCE and all the other common dependencies.  This does some nice things.  I can have a nice checkout script which puts all the right code in the right places. 

To start with I just dropped the CPP and H files in from folders into each project. However now things have got more complicated I've moved to the JUCE module format.  Just have a look at the juce_module_info file and give it a go. 

This avoids having to compile libraries separately. 

If you do want need to include a library there are a bunch of options in the Introjucer for setting up the right linkage.  Usually I end up doing static linking and just putting the path to the library (without the -l flag) in one of the boxes. 

I anticipate that there's an extensive discussion about static vs. dynamic linking on stackexchange if you want to get into the pros and cons.

I don't think there's any relation between 'Static LIbraries' and 'JUCE Modules'.  The modules are just a cute and easy way of including a load of source in your project with the hard work done for you!

FYI, in case anybody hits this thread later.

static and dynamic linking are both more difficult when you are talking about a single set of source code for multiple platforms.

We use 2 solutions:  (Jules can edit anything i get wrong)

1)  For files which are mature we use Modules.  Modules are awesome and easy which is why they are so hard to figure out.  No documentation so here it is.

        your source files for a module should all be under a parent folder.

        create a .mm file which just includes a .cpp file  (this seems to be for Macs.  Im guessing for some reason they use .mm instead of .cpp?)

         create a .h file.  This can include defines for configuring options in the Introjucer.  also includes your various .h files for the module

         create a .cpp file.  

         Look at any of the Juce modules for an example.

         modules can be anywhere, (they do not need to be the same place juce modules are)

         It can be easier to put them under the same parent folder if some modules depend on other module so the relative include paths are easier to work with.

        The preceding files are so any Os's compiler can build them.  Its much easier than trying to keep track of libraries for 5 operating systems.

        For the Introjuicer UI, create a file named "juce_module_info" and follow one of Juce's example files.

 There is probably a better explanation somewhere, but i couldnt find it.

(Juce feel free to edit this or point users somewhere else if it is better than my quick hack post)

2)  For files we are still developing, we just created a "common" project using jucer.

we then create a common folder under source in each juicer project and add existing files from the common project.

This lets us share the source without having to check it in to version control in each project we use it.



1 Like

Thanks, very useful info.