Code looks fine, but I did not test if it actually works. ;)

In D11882#239638, @alexeymin wrote:

Code looks fine, but I did not test if it actually works. ;)

It's a little hard to see the effect of this, because the installed extractor and the freshly built have to differ somehow. D11913 brought the necessity for this into the light.

Ping

In D11882#239725, @michaelh wrote:

In D11882#239638, @alexeymin wrote:

Code looks fine, but I did not test if it actually works. ;)

It's a little hard to see the effect of this, because the installed extractor and the freshly built have to differ somehow. D11913 brought the necessity for this into the light.

Maybe we can add a trivial dummy extractor which is used in unittests, but not anywhere else. It could e.g. return the current date, compilation timestamp (i.e. DATE), and the KF version.

In D11882#245719, @bruns wrote:

Maybe we can add a trivial dummy extractor which is used in unittests, but not anywhere else. It could e.g. return the current date, compilation timestamp (i.e. DATE), and the KF version.

I'm not sure if this wouldn't be too error prone. Every change in baloo_filemetadata_temp_extractor has to be accompanied by a respective change in the dummy.
Someone new to the code and not as skilled as you are might overlook that.
Also that wouldn't help much as in src/indexeddataretriever.cpp:

IndexedDataRetriever::start()
const QString exe = QStandardPaths::findExecutable(QLatin1String("baloo_filemetadata_temp_extractor"));

@bruns this diff tries to accomplish the same as D19268, and can be closed, right?