Plasma search and one other

[Duncan]

René J.V. Bertin posted on Thu, 23 Mar 2017 11:06:39 +0100 as excerpted:

> On Thursday March 23 2017 04:44:23 Duncan wrote:
> 
>>Note that until quite recently, plasma "required" baloo (the indexing
>>daemon) at build-time, failing configure with a baloo-not-found error if
> 
> Careful here. There's the Baloo framework which does indeed contain the
> indexing executables (on Linux) but I'm not aware that those are
> launched by default. They're not in my "Neon" style KF5 build.
> It's my understanding that the Baloo framework provides the basic
> functionality but that other dependencies (packages) are required to use
> the search and indexing features.

I believe other packages are required, yes, but my point was that the 
desktop itself required baloo until recently -- now it's an option, but 
I'm guessing still a required dep set at build-time on most binary 
distros.

And AFAIK, yes, the indexing can be run-time disabled (and without an 
index, calls to it won't do much), in fact, that being a primary argument 
of some for continuing to make it a non-optional dependency, but it's 
normally enabled as most distros ship kde/plasma.

> Why would they, none of them is using 32bit fossils anymore ;)

=:^)

>>But it finally was an official option again, so gentoo/kde could make it
>>a proper USE flag again, and I could drop my monkey-patches. =:^)
> 
> Pray tell, which packages and what's the name of the option? I don't see
> anything relevant in plasma-workspace and plasma-desktop (master
> branches).

It's plasma-workspace and plasma-desktop.  Gentoo/kde continues to use 
the semantic-desktop USE flag for it, just as it did in kde4, but I don't 
suppose that's what you're looking for. =:^P  Let me see what option they 
hook that up too in the ebuilds...

plasma-desktop and plasma-workspace appear to be similar:

First level (ebuild calls to eclass functions):

COMMON_DEPEND="
	...
	semantic-desktop? ( $(add_frameworks_dep baloo) )
"
...
src_configure () {
	local mycmakeargs=(
		...
		$(cmake-utils_use_find_package semantic-desktop KF5Baloo)
	)
	...
}

Second level (what the eclass functions actually do):

The COMMON_DEPEND stuff is gentoo-package-manager-specific dependency 
tracking, so I'll skip going further into it, but the cmake stuff is 
what's of real interest.

>From the cmake-utils.eclass manpage:

cmake-utils_use_find_package <USE flag> <package name>
	Based on use_enable. See ebuild(5).

	`cmake-utils_use_find_package  foo  LibFoo` echoes 
	-DCMAKE_DISABLE_FIND_PACKAGE_LibFoo=OFF
		if foo is enabled and
	-DCMAKE_DISABLE_FIND_PACKAGE_LibFoo=ON
		if it is disabled.
	This can be used to make find_package optional.

So the sources-configure-time argument to cmake is:

-DCMAKE_DISABLE_FIND_PACKAGE_KF5Baloo=ON/OFF

(But note that the function tries three package-name capitalization 
variants, so it might not be KF5Baloo but instead KF5BALOO or similar.)

>>But as I said, that's fairly recent.  Since I'm running live-git, I tend
>>to lose track of versioning and can't tell you exactly when the option
>>was introduced, but it's there now, even if somewhat recent.
> 
> Yes you can: check out the project, do a `git blame` on the file
> containing the option definition and check the annotation of the
> corresponding line ;)

... Or go lookup the bug and trace the conversation and git commit from 
there.

Either way, I'd then have to try to correlate that to a specific release, 
and I'm not yet persuaded that it's worth the bother for this thread, 
particularly when the git information is public and thus available to 
anyone that cares enough to go looking for it themselves, so I don't need 
to do it personally if I don't care about it /that/ deeply, particularly 
if the people asking don't care enough about it to bother, either.

So... s/can't/can't without a bunch of hassle I'd rather skip/

=:^)

> Let me guess, you ended up with
> /usr/usr/usr/usr/usr/usr/.../filenametoolong?

>From memory all I got as output was cmake's package-not-found error, but 
internally I suspect it was a failure to dereference one or more symlinks 
along the way, so it didn't see the directory let alone the file it was 
looking for.  Apparently an easy enough problem to work around in the 
*.cmake file, where they were actually being maintained, as no other 
packages had the problem, but with baloo effectively unmaintained...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman