New JUCE module format proposal!

Can you include a standard for using binary files inside of a module?

We have a library of standard plug-in code that we use on all of our projects, and we're working on converting it to a module. As part of our library, we have a few SVG files that we use for various buttons. Currently, this is easy to maintain with Introjucer, as we add those SVG files to every project, and the BinaryData file gets generated automatically.

It would be great to have a smaller-scale module option, or a module-building helper program like Introjucer. The best option for modules that I can currently think of is to use the command-line BinaryBuilder and maintain those files separately.

 

Regarding local copy, it's an option I would hate to see disappear. The current "Copy all the time or copy never" method is flawed though, as I hate that the entirety of JUCE gets copied anytime I resave the project. Fix a header include path? Resave JUCE.

It would be great if there were a button to force a local copy of JUCE files. Git submodules are fine, but it adds one more annoying step when working with a team (i.e. git pull, then submodule update). Local files can help reduce frustration in that regard.

1 Like

As for parsing the BEGIN_JUCE_MODULE_DECLARATION at the beginning of the file, if you want it to be part of a commented out section (which I totally favour instead of a #if 0 guard), please support the case of a block commented out with line comments or with the asterisks that come at the beginning of each line in a javadoc-style comment, e.g.

// BEGIN_JUCE_MODULE_DECLARATION
//      ID:               juce_audio_devices
//      vendor:           juce
//      version:          4.1.0
//      name:             JUCE audio and MIDI I/O device classes
//      description:      Classes to play and record from audio and MIDI I/O devices
//      website:          http://www.juce.com/juce
//      license:          GPL/Commercial
// 
//      dependencies:     juce_audio_basics, juce_audio_formats, juce_events
//      OSXFrameworks:    CoreAudio CoreMIDI DiscRecording
//      iOSFrameworks:    CoreAudio CoreMIDI AudioToolbox AVFoundation
//      linuxLibs:        asound
//      mingwLibs:        winmm
// END_JUCE_MODULE_DECLARATION

or


/*
* BEGIN_JUCE_MODULE_DECLARATION
*     ID: juce_audio_devices
*     vendor: juce
*     version: 4.1.0
*     name: JUCE audio and MIDI I/O device classes 
*     description: Classes to play and record from audio and MIDI I/O devices 
*     website: http://www.juce.com/juce 
*     license: GPL/Commercial 
*
*     dependencies: juce_audio_basics, juce_audio_formats, juce_events
*     OSXFrameworks: CoreAudio CoreMIDI DiscRecording 
*     iOSFrameworks: CoreAudio CoreMIDI AudioToolbox AVFoundation 
*     linuxLibs: asound
*     mingwLibs: winmm
* END_JUCE_MODULE_DECLARATION
*/

Had I to implement that parsing, I'd parse the lines between BEGIN and END_JUCE_MODULE_DECLARATION starting from the first alphanumeric character, ignoring any whitespace or symbol that comes before that.

 

With local copy disabled by default you're more or less discouraging people to use it, but I wouldn't mind seeing it stay. I have found it quite useful in the past..

Yes, good point! Thanks, I'll take that onboard.

Yes, we'd certainly like to add some support for binary code in modules, either static or dynamic, as that'll let people build closed-source modules. Might not put this into the initial spec, but it's definitely in our plans!

did the OSXLibs entry disappear in 4.2? Could we have it back? :slight_smile:

No, it’s still supported! And the setting is still called “OSXLibs”. Does it not work for you?

I don’t think it is working correctly. Here is a video to demonstrate:

https://www.dropbox.com/s/gwah7461xovdbnt/OSXLibs.mov?dl=0

Can’t see the video for some reason… But the code looks good to me, in jucer_Module.cpp, line 327. Can you debug and see what’s going wrong there in your case?

I have been able to successfully see the video by right-click, “Open in new tab”, then skipped the prompt for creation of a Dropbox account clicking the “Continue to video” link below that.

ok debugging. i updated the post with the video. download it to get a higher res version. dropbox player makes it hard to read the text

jules - i just sent you a patch which fixes OSXLibs for me. It involves modifying XCodeProjectExporter::Target::getLinkerFlags() to add libraries from owner.xcodeLibs rather than this::xcodeLibs

I am not 100% sure it is correct since I haven’t fully understood the code and worked out where XCodeProjectExporter::Target:xcodeLibs should be used if at all.

Thanks Oli! Your fix wasn’t quite right, but pointed me in the right direction - should hopefully be OK now!

I use local copies as a workaround to make android builds succeed on Windows. Without a local copy the Android NDK c++ compiler fails with errors about not being able to find header files. Probably because the relative include path length for juce module files is too long. Moving the project’s code closer to the filesystem root does not solve it. And alas, moving to a mac for debugging android builds is not an option for me currently.

So if that problem could be fixed, I could live without local copies

We have problems browsing the source code in modules containing multiple levels of subdirectories. Previously, you could specify browsable dirs with the “browse” value in the JSON file. There doesn’t seem to exist a header-file value for this?

Does the new module format require a semi-flat directory structure inside the module itself, with only 1 sub-directory level?

You can reproduce this problem by marking “juce_audio_plugin_client” as browsable in Projucer. Then you won’t be able to see source files in, for example AU/CoreAudioUtilityClasses, since it’s 2 levels deep in the directory structure.

(tested with XCode)

Ah, sorry, it’s just a typo, it should have been searching for folders recursively… Have fixed it now, thanks for letting us know!

Excellent, works fine now. And very convenient not having to specify this manually, like before.

Looks like this new format has now been implemented. Should this Juce Module Format page be updated to match?

1 Like

Yes, it should! Thanks for the heads-up, we’ll update that page…

is there a way to add .cpp files to a module WITHOUT using #include “x.cpp” ?
I’m building a module out of some thirdparty source and it doesn’t like being included that way.

If I’m not mistaken the old module format allowed to specify .cpp files without a need for #include, so that each .cpp file would show up as an individual file in the generated VS/Xcode solution?