I’m having a bit of a problem trying to compile a Juce app including Doxygen. They both use libpng, and so they conflict when I try to build, giving me lots of errors like
jucelib_static_Win32_debug.lib(pngtrans.obj) : error LNK2005: _png_set_bgr already defined in libpng.lib(pngtrans.obj)… so I removed ‘libpng.lib’ from the libs being linked in, and now i get just one error…
any idea what i should try? this is the first time i’ve really tried combining libraries.
probably doxygen is using the whole libpng, while the png files in the juce codebase are stripped down for reduce size: for that you getting errors that some symbols are unresolved.
you should add those missing files or functions in the juce png files (it’s better than make juce compile with an external libpng.lib, cause i think jules modified some files for convenience)…
argh, i’m going round in circles.
The thing i’m having problems with is ‘png_init_io’ - some function used to initialise the file before writing to it. This is only defined if ‘PNG_NO_STDIO’ is NOT defined.
Juce has PNG_NO_STDIO defined, i believe to make sure that the STDIO stuff isn’t all linked in, bumping up its size. Fine by me, but when doing this, it forces an alternative ‘callback’ method of writing the files instead of png_init_io.
Doxygen uses the png_init_io method, and I have no idea how i could possibly get the two aligned. Why can’t I just let them both exist in their own way? I know it’d make things bigger but it’d save so much hassle!
okay, i thought i’d try and abuse the Juce png writing stuff - try to get doxygen’s writing part to do the same thing as juce, but i’m megabaffled.
the callback function casts the png data struct to an OutputStream*… and then calls ->write(…) on it. How?! It’s an abstract class, right? And the pointer it’s just cast from isn’t of any subclass of OutputStream…
how does this work?!
if you look here:
jules is setting:
to be the real output writing method (for storing the png somewhere), passing
OutputStream &out as void* (that he got back as pointer in the pngWriteStruct)
i’m not sure if setting a callback is enough - the stuff that comes after his setting of the callback is very different to the alternative ‘write’ …
doxygen has
png_init_io(png_ptr,file);
png_write_png(png_ptr,info_ptr,PNG_TRANSFORM_IDENTITY,NULL);
and then that’s it! juce has loads of stuff after setting the callback that doesn’t appear in doxygen’s one… and they both use different structures. it’s a bit of a nightmare!
you will only use:
png_init_io(png_ptr,file);
png_write_png(png_ptr,info_ptr,PNG_TRANSFORM_IDENTITY,NULL);
if you got a FILE struct to write to. For that’s is so simple.
Juce doesn’t need png_init_io just cause jules is using callbacks for the real write implementation (using juce streams instead of plain FILE structs, so permitting to stream the content of a png into memory instead of into files).
you should try to make juce compile-in “png_init_io” again, avoiding it to call any of those…
thanks for your help, i’ve managed to get it to compile now. i didn’t think i’d be able to simply enable that function in juce without breaking the alternative method it implements… but i guess it doesn’t matter!
now i have a really annoying problem - even though my test build app doesn’t actually DO anything with the doxygen files, and i’ve deleted the #include so it’s not even including any doxygen code… i get masses of leaking objects on program close, and its just doxygen stuff! (the fragments of data that appear in the dump breakdown only occur in the doxygen source).
how the heck could this be??
I’ve managed to get rid of most of the leaks, but in a weird way.
There’s a file called ‘CmdMapper.cpp’ which has a load of stuff allocated
CommandMap cmdMap[] =
{
{ "a", CMD_EMPHASIS },
{ "addindex", CMD_ADDINDEX },
...
literally loads of these...
...
{ "summary", XML_SUMMARY },
{ "value", XML_VALUE },
{ 0, 0 }
};
//----------------------------------------------------------------------------
Mapper *Mappers::cmdMapper = new Mapper(cmdMap);
void Mappers::freeMappers()
{
delete cmdMapper; cmdMapper = 0;
}For some reason, the line where this all gets instantiated is called before juce has even been initialised. I can’t find where this is told to happen, but I’ve managed to access the ‘freeMappers()’ function in my app destructor.
The odd thing is, these leaks don’t appear in the output of the ‘normal’ (command line) Doxygen; my debugger shows the instantiation still happens at the start, but my breakpoint in freeMappers never gets called! Could it be that the leaks are just not detected because it’s a command line app?
What on earth are you trying to build?!
Just a thought, but maybe it’d help with your link problems if you used juce as a DLL rather than statically linking it?
well first of all i wanted to just make a simple app that used Doxygen as a commandline tool, for creating Juce documentation using a custom-generated config file (where the user specifies their juce directory, and then it adapts the config you sent me accordingly before calling the command).
Then, when I saw the source was available, I thought it’d be nicer to actually use the doxygen code directly within the app, so it’s all nice and self contained. That seems like a reasonable enough thing to try
Then I figured, well - the doxywizard is all well and good but it’s still a massive pain in the arse. It’s about time Doxygen had a nice user friendly interface, where you can just worry about the things you actually care about - a streamlined GUI based app with a few basic, intuitive settings that you can use specifically to build dox for C++ code. There’s no reason not to expect to have a single window app that can generate documentation, that doesn’t rely on using an external command line tool.
I’ve considered using Juce as a DLL but… well, I want it to be a nice simple Juce application that does doxygen, rather than doxygen with added juce, if you know what i mean?
Good thinking - doxygen is great, but the UI is hopeless!
