Please change the behaviour of debug stdout/stderr output.

[emmenlau]

I have a kind request about the exiv2 sources. I see that debug builds use the define DEBUG to print more verbose output messages. These messages are directly written to std::cout or std::cerr.

This behavior is quite common and there is really nothing wrong with it. However I would slightly prefer more control over the messages, because when I use exiv2 debug builds, they tend to be quite verbose on stdout/stderr.

Would it be acceptable to change the logging behavior? I could think to either add a new define like EXIV2_DEBUG_MESSAGES that users can separately control independent of DEBUG. Or to leave the messages to be printed only when DEBUG is defined, but print via exiv2's existing logging mechanism from error.hpp so users can control the verbosity at runtime.

Does any of this sound reasonable? If you find it not worthwhile, please feel free to close this kind request.

[clanmills]

Thanks for this suggestion and we could do this.

Let me make a comment. The DEBUG symbol is intended to be set by the user for "occasional" use and not "blanket coverage". This is discussed in README.md 2.11 2) About preprocessor symbols NDEBUG and DEBUG.

I expect other team members will wish to comment. Let's reach a consensus and then agree on action.

[emmenlau]

Thanks @clanmills for your quick and helpful reply!

I agree that setting DEBUG for blanket coverage is not super clean from my side. In my defense, I build some 30+ debug builds on Windows and they all happily accept the DEBUG define for additional helpful internal code checks and extended logging. So I am actually quite happy with exiv2's behavior! Only the current verbosity is a (small) issue for me because opening a single file can print 3-5 pages of internal messages which I can not redirect easily to my logger.

So please forgive if this request may be a rather unique use case and not so relevant to the general public. But if debug logging would go through the exiv2 logger, or use a separate define, it would be quite helpful for me.

[D4N]

I think having a compile time settable verbosity or a compile time switch for the logging is a good idea. I wouldn't mind to have instead of #ifdef DEBUG #endif: #ifdef EXIV2_DEBUG_MESSAGES #endif around the debug output.

I don't think that we should implement a runtime verbosity setting though. Such an option would be very painful on Unix where shared libraries generally exist only once in memory for all applications that link against them. I.e. any application could change the verbosity for every other application linking against libexiv2.

[clanmills]

Having a library run-time logging verbosity setting (default = 0, or EXIV2_DEBUG_VERBOSITY) would be process-wide and not machine-wide.

We wish to avoid API changes in the Exiv2 v0.27 "dots". While adding a new API doesn't hurt, it is something to avoid.

[clanmills]

Re-opened. No idea how this issue was closed in error (cat jumped on the keyboard).

[D4N]

Having a library run-time logging verbosity setting (default = 0, or EXIV2_DEBUG_VERBOSITY) would be process-wide and not machine-wide.

That's only true if the variable that sets the logging verbosity is in the address space of the process linked against libexiv2. If the verbosity setting is however inside libexiv2, then the setting is global for all applications linked against libexiv2. (This only applies on Linux and maybe on other Unixes, on Windows shared libraries behave more like static libraries in that regard and each process get's their own copy of the shared library).

[clanmills]

I'm setting the target to v0.28. I don't want to modify the behaviour or settings or API for v0.27 "dots". @emmenlau I recommend building without setting DEBUG.

@D4N: Windows DLLs are shared when located on the PATH. Most applications have copies of DLLs in the same directory as the .exe and use that copy because that directory is considered to be on the PATH. Unix systems usually find the shared library in a "standard" location such as /usr/local/lib and are therefore more commonly shared. Windows doesn't have a "standard" location. Microsoft usually put their DLLs in c:\windows\system32 and in ancient times, applications could use that directory to share system-wide DLLs.

[D4N]

Robin Mills <notifications@github.com> writes:

I'm setting the target to v0.28. I don't want to modify the behaviour or settings or API for v0.27 "dots". @emmenlau I recommend building without setting DEBUG.

Yes, any change with regard to this should go into the master branch.

@D4N: Windows DLLs are shared when located on the PATH. Most applications have copies of DLLs in the same directory as the .exe and use that copy because that directory is considered to be on the PATH. Unix systems usually find the shared library in a "standard" location such as /usr/local/lib and are therefore more commonly shared. Windows doesn't have a "standard" location. Microsoft usually put their DLLs in c:\windows\system32 and _in ancient times_, applications could use that directory to share system-wide DLLs.

I think we are talking about different things here: I meant that I do not want to add runtime code like: Exiv2::set_verbosity(verbosity_t verbosity) I'm fine with a compile time switch in addition to the DEBUG macro, as that is clearly intended only for debugging purposes and not for system-wide installation.

…

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #926 (comment)

[piponazo]

Hi guys!

As @D4N said, I would not mind either to replace DEBUG with EXIV2_DEBUG_MESSAGES to avoid these situations. I have seen the usage of DEBUG in many libraries and it could be that user users come with similar requests (Although it is clear that we are not doing anything wrong in our side).

If we do that ... could not we do it in 0.27-maintenance ? Right now we are not using the DEBUG definition in the public headers. I do not see an impediment to do that, but I might be wrong ...