I just wanted to post a quick description of some big structural changes that I’m currently planning, and hopefully get some feedback from you good folks about it.
Having spent the last couple of years happily letting the introjucer do all the dirty-work involved in knitting the juce library into my application projects, I’ve become more and more convinced that the best way to use libraries in C++ is just to let a tool automatically stuff the library’s cpp files into your projects, and to avoid all the messing-about with static libs. The introjucer does this really well by having a lot of custom code that understands how the juce library works, but I’ve been figuring out a way to extend the same technique to a wider range of libraries.
So… Phase 1 of my cunning world-domination plan will involve the following changes:
- I’ll break the juce library up into about a dozen smaller modules. Some of these will be dependent on other ones (e.g. there’ll be a “core” unit that all the others depend on), but you’ll be able to choose which modules you use in your project. So if you don’t need a GUI, you don’t need to include that module; if you don’t need audio, you won’t need to waste time including or bloating your app with those classes.
- I’ll design a format for a library descriptor file (user-editable, in JSON or XML), which describes a c++ library module. This will contain its name, version, dependencies, header files, cpp files that need to be included in the app that uses it, etc etc. Each module will be uniquely identified by a URL, from which it can be downloaded (in a special kind of zip file).
- One of these library module zip files contains just the raw source code, and the library descriptor file. There will be no makefiles or anything platform-specific in there, as the library will never be compiled except as part of another project.
- When creating an introjucer project, your app’s project will specify a set of library modules that it requires, and the introjucer will be able to go off and automatically fetch each of the library modules by downloading its zip file.
- The libraries that your app uses will be unzipped into a sub-folder (hidden away in the introjucer’s auto-generated files area). The library’s header files will be automatically added to your main app header, and all of its cpp files will be added to the project (in the same way that the juce amalgamated files are added now).
So… having extended the introjucer to be able to deliver any library, the next logical step will be to allow all of you guys to use it for your own libraries. The introjucer needs to have a list of all available libraries, so it’ll connect to juce.com for that information - so, as well as listing the standard set of juce modules, I’ll also be able to include 3rd party modules in there. That means that if you’re on the list, somebody will be able to download your library and incorporate it into their project by simply ticking a check-box in the introjucer.
There are lots of little details that I need to flesh-out, (e.g. versioning), but hopefully this will give you the gist! None of it’s particularly difficult to implement, but could create a great platform for easy installation and management of c++ libraries. Comments and opinions welcome!