zlibNamespace, pnglibNamespace and jpeglibNamespace


#1

im getting into a right tangle with all these namespaces

juce puts zlib, pnglib and jpeglib into its own name spaces.

im trying to supply my own versions of zlib, pnglib and jpeglib. presumably this is what the settings; JUCE_INCLUDE_PNGLIB_CODE, JUCE_INCLUDE_JPEGLIB_CODE and JUCE_INCLUDE_ZLIB_CODE do. However, when i set these things, it doesnt work because juce expects the relevant libs to still be inside, eg, namespace juce::pnglibNamespace.

I dont want any of these hidden inside a namespace because that’s precisely why im supplying external versions - so that my app code can call them!

it seems that supplying external version can never work.


#2

Can’t you just leave the JUCE ones as they are and supply your own? They shouldn’t clash as they’ll be in different namespaces. Yes, its not ideal because you’ll have effectively 2 copies of the same code but should work. I think the JUCE_INCLUDE_PNGLIB_CODE etc. flags are just there to disable this functionality in JUCE altogether.


#3

Hi Dave, thanks for your idea.

I have now figured out what’s going on. You can supply external versions and leave juce to think it’s using its own namespace. Personally, i think it’s a mistake for juce to try to namespace them. The reason why it works is because, currently these libs are all C linkage, so whatever the namespaces, they link to the same function names! This obviously means that the juce namespacing isnt preventing a clash of names at all.

I like the way juce doesnt need external dependencies to be installed by the user, but perhaps it should simply come supplied with those dependencies [ie versions known to work] and those dependencies not be hidden or encapsulated. That way, your code could access features of those libs directly when required and it would be straightforward to try to upgrade them for projects that need the very latest versions.

Then there’s the problem of new and exciting formats and how they might be added. For example, yesterday i was looking into supporting the WebP image format.

My image support is moving more and more outside of juce; for example so that i can get to jpeg metadata. Really, this means that juce isnt doing it for me when, in fact, that’s what juce is supposed to do.

After all, i just want to load images!


#4

(I seem to remember recently tweaking the extern “C” stuff to make sure that all these symbols are hidden away correctly)

The reason for all this namespacing is that people inevitably need to be able to link their apps with 3rd-party stuff which may drag-in all kinds of random versions of these libs, so if I expose them in any way, it’s bound to screw someone up - I think my only option is to keep them internal and well-hidden to avoid clashes.