Would it be possible to disable JUCE8 JavaScript implementation, or have a possibility to switch it back to the legacy one? I have projects that use QuickJS, and because JUCE sneakily embeds choc’s QuickJS wrapper, migrating to JUCE8 is problematic for me (even thoug QuickJS in choc is wrapped in a namespace, is contains plenty of macros that cause conflicts). I can switch to using QuickJS implementation from JUCE8, however the one wrapped in choc does not have features I need (like JSX syntax support or modules loading).
*edit: misspelled choc.
Can you provide some examples of the errors you’re seeing? It looks to me like JUCE only includes CHOC via juce_core.cpp, so JUCE’s quickjs symbols shouldn’t be visible outside JUCE’s implementation. Similarly, symbols from an external quickjs shouldn’t clash with JUCE unless the external quickjs header is being included in the juce_core translation unit. I can imagine this happening if you’re using precompiled headers, but it’s unlikely otherwise. Are you using precompiled headers? If not, how and where are you including quickjs?
I believe we are looking at updating the bundled QuickJS in the near future, but things might take a bit longer than normal given that the team is busy with the upcoming Audio Developer Conference.
Thanks for the reply. I include it as a JUCE module, i.e. the QuickJS headers get exposed (but the QuickJS itself is statically linked, please see here: GitHub - Archie3d/VITRO: JUCE Declarative UI module). I can get around it by including juce_core/javascript/choc/javascript/choc_javascript_QuickJS.h instead, so updating QuickJS in JUCE would work as well (perhaps use CMake flags to enable JSX and other QuickJS features in choc).
I still don’t understand where the symbol collisions are coming from. Even if your module includes quickjs, this shouldn’t affect the compilation of juce_core. Where exactly are the errors coming from? Can you provide some examples of the errors you’re seeing?
Ok, I think I found where the problem is. My QuickJS implementation has CONFIG_BIGNUM macro defined for big numbers support in JavaScript. Choc’s wrapper does not compile with CONFIG_BIGNUM (though it still checks for this macro) - the code needs to be C++fied. For example, this
JSBigFloat *p = JS_VALUE_GET_PTR(val);
should be
JSBigFloat *p = (JSBigFloat *)JS_VALUE_GET_PTR(val);
etc.
I see that Choc does this in all other places except for #ifdef CONFIG_BIGNUM blocks. Also libbf.h is missing (part of QuickJS), but it was taking it from my instance of QuickJS, that added to the confusion.
So, basically removing CONFIG_BIGNUM from my project let it compile with JUCE8 (but without support for big numbers in JavaScript). I can live without big numbers atm, but Choc probably needs to be sanitised in this regard.
Would it be possible to just move JUCE’s JS into a separate module? 99% of projects don’t need JavaScript and it would be great to not compile/link against it unless needed.
9 Likes
We’ve pushed some updates to develop.
The javascript implementation will now warn if CONFIG_BIGNUM is enabled, if there is more demand for it we may look at supporting that setting but for now we’ve decided to always disable the setting for the internal version.
Additionally we’ve moved the javascript implementation into a separate module as suggested by @eyalamir as none of the other modules depend on it and many projects won’t need it, so hopefully in your case @archie3d you should find the JUCE javascript implementation is not included by default.
For anyone who does need the Javascript implementation they will need to include the new juce_javascript module in their projects.
2 Likes
Excellent, much appreciated!
1 Like
Nice work! Love seeing stuff like this.
2 Likes