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.
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, 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!
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.
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.
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.
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?
