# Compile juce modules to static libraries

**URL:** <https://forum.juce.com/t/compile-juce-modules-to-static-libraries/43255>\
**Category:** General JUCE discussion\
**Created:** [December 15, 2020, 11:15am UTC](https://forum.juce.com/t/compile-juce-modules-to-static-libraries/43255 "2020-12-15T11:15:21Z")\
**Posts on this page:** 1\
**Showing post:** 11

<div class="post-metadata">

**Author:** ![vallant](https://avatars.discourse-cdn.com/v4/letter/v/c57346/32.png) [@vallant](https://forum.juce.com/u/vallant)\
**Post date:** [December 28, 2020, 9:25am UTC](https://forum.juce.com/t/compile-juce-modules-to-static-libraries/43255/11 "2020-12-28T09:25:29Z")

</div>

> [@reuk](#):
>
> Currently all of that behaviour is controlled by a single flag; if we moved away from the preprocessor, we’d probably have to require users to manually link an 'juce\_ogg\_vorbis` staticlib containing the definition of the vorbis audio format, and then require users to manually register this format in an AudioFormatManager before use.

So, all the compiling overhead that is needed for ogg isn’t really an issue in my eyes, since this could be built as a static library too. Other than that- registering the ogg format instead of using the preprocessor-flag is exactly what i had in mind. And while the users might have to do more to setup the project (at runtime, instead of compile time too!), at least for me personally it would make it easier to understand how the modules interact with each other, and where some functionality comes from.  
But i see that the preprocessor-defines are so baked-into juce that it would be hard to make such a change.

---

_[View the full topic](https://forum.juce.com/t/compile-juce-modules-to-static-libraries/43255)._
