[Interest] QML preprocessing
roland at logikalsolutions.com
Sun Apr 28 16:00:44 CEST 2019
You have brought up yet another of the limitless reasons QML and
Pull down this zip file.
(It's discussed in the "Raspberry Qt" post series on logikalblog.com)
Take the LogikalLogger class. It's a singleton. Add it to your
application. I typically "expose" it by creating a Backend class which
is then registered with QML and instantiated by main.cpp.
Forget the console.log() abomination ever existed. Always use
backEnd.logDebug() or logCrit(), etc. (Critical typically also includes
a call to the wrench screen to hide the screen before ending the
application. Critical means one cannot safely continue without adverse
outcome to human life.)
If you always use your logDebug() wrapper (or expose LogikalLogger
directly and pass the various syslog values) no Debug level messages
will ever be recorded or displayed when the application is not compiled
with debug. For some clients I have even modified versions of this to
include a set/get methods for "minimum log level" so it could be
controlled from the command line at startup. This allowed them to weed
out INFO and under messages but still keep warning on up.
anything because they are unfit for production use.
On 4/25/2019 3:59 AM, Alexander Ivash wrote:
> I understand that this topic was raised a lot of times and that this
> is not QML-way. But, what options do I have in case of requirements to
> eliminate all the logging for release builds?
> Is there any hidden magic in qmake, like 'QMAKE_SUBSTITUTES' but more
> flexible to substitute all the 'console.debug....' with '//
> console.debug' right before adding qml into resources?
> p.s. Yea, I'm aware of selectors, but would like to avoid having both
> component-with-logging.qml and component-with-no-logging.qml
Roland Hughes, President
More information about the Interest