Allow a QString in a logging request when 'Qt support/integration' is ON

[swebb2066]

When log4cxx is built with 'Qt support/integration' ON, the built library can be named log4cxxqt by defining LOG4CXX_LIBRARY_SUFFIX=qt .

The QtCore library is a required dependency (statically or dynamically) when 'Qt support/integration' is ON.

[rm5248]

Note: I specifically did not do this, because I don't want to have log4cxx depend on Qt at all, even optionally. This is so that Linux distros can package up log4cxx and log4cxx-qt separately. At least on Debian-based systems(unless something has changed recently), if log4cxx was built with Qt support the symbols would be in the .so file, and thus it would bring in all of the Qt libraries(even if your app does not use Qt). Because they are two separate .so files, you only get the Qt libraries if you need the Qt support.

Having a Logger that does let you log QStrings directly would be convenient, but I'm not quite sure how to make that happen.

[swebb2066]

When 'Qt support/integration' is ON, the target name can be different,. say log4cxx-qt.

[rm5248]

Would that allow both libraries to be installed at the same time and not overwrite each other?

These are the options as I see it:

• build both log4cxx and log4cxx-qt using the same sources at the same time(assuming Qt support is on). The two libraries are basically the same at that point, but the log4cxx-qt library has extra symbols for use with Qt.
• Build one or the other. I don't really like this option, since in my mind the core library shouldn't really depend on any 3rd party libraries. and it means that you would need to configure twice to build the library, instead of configuring once and having two libraries.
• Add overrides for operator<< and fmt that take in a QString. This doesn't make the API easier to use, but it makes logging easier.
• Create a QLogger class that extends Logger, taking in a QString parameter.
• Do nothing

The third option seems like the easiest to do to make logging easier. The fourth would work somewhat but because of the LoggerManager that tracks the loggers, we would probably need to create a separate QLoggerManager as well. Unifying those two may be difficult.

[swebb2066]

Would that allow both libraries to be installed at the same time and not overwrite each other?

Yes, however my view is that the libraries would be in separate 'packages'. An application would use one or the other, but both could live in the one machine/container. The 'with_qt' option in the conan package manager enforces the creation of a separate package.

The conversion of non-logchar character types into std::basic_string<logchar> (currently in logger.cpp rather than in messagebuffer.cpp) is the consideration that goes against the fourth option.

Do nothing is of course the easiest option, but ...

[rm5248]

Would that allow both libraries to be installed at the same time and not overwrite each other?

Yes, however my view is that the libraries would be in separate 'packages'. An application would use one or the other, but both could live in the one machine/container. The 'with_qt' option in the conan package manager enforces the creation of a separate package.

FWIW the way that it is currently setup is designed to be packaged easily as a Debian package. Both libraries can get built at the same time and then sent to different packages depending on the name/location of the file. I'm not sure if Conan does it the same way.

[swebb2066]

FWIW the way that it is currently setup is designed to be packaged easily as a Debian package

Do you know if the Debian package is currently built with LOG4CXX_QT_SUPPORT defined?

To create a separate Debian package with LOG4CXX_QT_SUPPORT, they would now need to define LOG4CXX_LIBRARY_SUFFIX=qt. The installed library will then be named log4cxxqt and the QT enabled header files (log4cxx.h is different) will be installed under /usr/include/qt/log4cxx.

The way other package managers work (e.g. conan, vcpkg) made it is necessary to make the suffix optional. They would not define a suffix as the install directory is not shared.

[rm5248]

The debian package is not currently built with Qt support. The maintainer is @coldtobi , he may have better insight than me though.

I do have an idea on how to make the first option(build two libraries) work, if I get time this weekend I may try to do a standalone proof of concept of that.

[coldtobi]

The debian package is not currently built with Qt support. The maintainer is @coldtobi , he may have better insight than me though.

It shouldn't be a problem to compile log4cxx in several flavours, for Debian.
(Details of course have to be checked as I'm not a QT expert.)

One problem I could think of: If the QTfalvour contains not only the QT parts, but also the regular library bits, there could be issues if a project (implictly) is using both. (e.g a library using liblog4cxx, but not the qt flavour ; a project then using QT and this library. This might create issues, as two libraries with the same symblols will be loaded and then if might not be deterministic which one is used when.)

Is it possible only to have the QT parts in the qt library and the qt library using "under the hoods" the regular one?

[swebb2066]

there could be issues if a project (implictly) is using both

The application code would not be able to use the Qt API methods if they depend on a component that uses a non-Qt flavour liblog4cxx (not a common occurance), unless they could rebuild the component against the liblog4cxxqt library.

Is it possible only to have the QT parts in the qt library and the qt library using "under the hoods" the regular one?

As Log4cxx is a C++ API, the interfaces are class methods which cannot be separated AFAIK.

[rm5248]

there could be issues if a project (implictly) is using both

The application code would not be able to use the Qt API methods if they depend on a component that uses a non-Qt flavour liblog4cxx (not a common occurance), unless they could rebuild the component against the liblog4cxxqt library.

The problem Tobi is talking about is if we have:

application
 --> libexample.so --> liblog4cxx.so
 --> liblog4cxxqt.so

The same symbols would be in both liblog4cxx.so and liblog4cxxqt.so. We could change the namespace if the library is built with Qt though, but that doesn't seem too fun either...

Is it possible only to have the QT parts in the qt library and the qt library using "under the hoods" the regular one?

As Log4cxx is a C++ API, the interfaces are class methods which cannot be separated AFAIK.

If we're adding methods to support QStrings, that sounds correct to me. The current Qt support is in a separate library so it does not bring in any Qt methods. So I would be more in favor of just adding an operator<< support for QString, which should handle most of the logging cases.