I’m actually working on a small handful of modules that I want to publish. I’m cleaning up the code so it is presentable.
cool, how do you manage your modules with git? Do you simply clone the whole juce tree and put your stuff in it, or did you figure out a neater way to do it (i.e. some setup that would allow to easily pull the most recent juce & plus your most recent modules).
That’s a sore subject!!! I’m still struggling with setting up git and my project’s layout efficiently. To answer your original question, it is not necessary to put 3rd party modules in the juce tree. They can pretty much live anywhere.
However, what Jules has done with this new module source code layout, is create a steady pressure on any project that uses juce, but is itself a subproject, to mimic the module style of including the .cpp directly in the host rather than building as a static library.
Its very easy to lay out an application or plugin that uses Juce. But if you’re trying to build a library on top of Juce, meant to be inserted into another app or plugin, it is more difficult. There is the issue of AppConfig.h - this header is needed every time a Juce header is included. But AppConfig.h is owned by the application, not the 3rd party module.
Another conflict happens when writing a library that depends on another 3rd party library (although this is not specific to Juce). I have tweaked the soci db api and made it work stand-alone with sqlite only, along with some data translators that let you use native Juce types (like String) in SQL statements. At some point sqlite.h needs to be included. Where does it come from? Does the user have to configure some header file? That would change their local copy, something I’m trying to avoid.
Yet another example, I have my FreeTypeFaces object in this library. It needs FreeType in some form. There are three ways to do this, statically link with the sources, dynamically link with the operating system provided FreeType, or the third way, static link with the amalgamation. How does the user set this up? Again there’s the problem of forcing people who use my library to make local changes.
Of course…having some sort of shell script that figures this all out and generates appropriate .h files might resolve it. autoconf anyone? I hate tools like that.
It seems that Juce is discouraging traditional project files (i.e. .vcxproj or .xcodeproj) in a distribution of a library which depends on Juce.
So how you make the IntroJucer pick them up if they are not in the juce/modules directory?
IntroJucer? What’s that?
IntroJucer integration outside the juce folder might require some changes from Jules. I don’t know much about IntroJucer, I’ve never used it.
I know your opionion about the introducer, but there is another thread for that. And I do share a lot of your concerns, since we are using cmake to generate our projects and solutions. However it is probably the preferred way for many to generate juce projects, so I do wonder what is the best way to add 3rd party jules modules. (But there is another thread for that as well.)
I will post there