[dolphin] [Bug 495620] New: fdf854bd8 broke dolphin configure/build without KF6FileMetaData

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=495620

            Bug ID: 495620
           Summary: fdf854bd8 broke dolphin configure/build without
                    KF6FileMetaData
    Classification: Applications
           Product: dolphin
           Version: git-master
          Platform: Compiled Sources
                OS: All
            Status: REPORTED
          Severity: normal
          Priority: NOR
         Component: view-engine: general
          Assignee: dolphin-bugs-null at kde.org
          Reporter: 1i5t5.duncan at cox.net
                CC: kfm-devel at kde.org
  Target Milestone: ---

The commit below breaks building dolphin without baloo and KF6FileMetaData,
moving it out from under if(HAVE_BALOO) conditional:

> Git commit fdf854bd81d9e42df2d8672d49a0b7fcdb7443a5 by Méven Car.
> Committed on 27/10/2024 at 17:20.
> Pushed by meven into branch 'master'.
> 
> ViewProperties: Store view properties in extended file attributes

(snip some... only listing the file triggering the error)

> M  +1    -1    src/CMakeLists.txt


I run live-git for most of kde (frameworks/plasma/gear-apps) using the ebuilds
for that purpose in the gentoo/kde overlay.  I have USE=-semantic-desktop set,
which for dolphin translates to:
-DCMAKE_DISABLE_FIND_PACKAGE_KF6Baloo=ON
-DCMAKE_DISABLE_FIND_PACKAGE_KF6BalooWidgets=ON
-DCMAKE_DISABLE_FIND_PACKAGE_KF6FileMetaData=ON

The problem is that commit moved target_link_libraries  KF6::FileMetaData out
from under the if(HAVE_BALOO) conditional into the generic/unconditional
target_link_libraries, in the above src/CMakeLists.txt change.

The result is that configure now breaks with:

CMake Error at src/CMakeLists.txt:199 (target_link_libraries):
Target "dolphinprivate" links to:

KF6::FileMetaData


Moving the KF6::FileMetaData back under the if(HAVE_BALOO) conditional in
CMakeLists.txt gets past the config breakage, but unsurprisingly breaks further
into the compile, since the new code is assuming FileMetaData is there when
it's not.  Unfortunately I'm not a dev and that's about the limit of my easy
test-hacking.

Meanwhile, I /do/ have the (KF6) kfilemetadata framework installed as a dep for
other things (ark and plasma-browser-integration seem to require it on gentoo
at least,  while gwenview, and dolphin before this commit, had it optional
based on USE=semantic-desktop).  Maybe that's all that's needed and it just
needs conceptually split off from the baloo dependency it was previously under
(at the gentoo level to match the new upstream?) and the
-DCMAKE_DISABLE_FIND_PACKAGE_KF6FileMetaData option removed with the dependency
required/forced?

But if so that would seem to need a deliberate upstream dolphin decision,
indicated by removal of the the upstream
-DCMAKE_DISABLE_FIND_PACKAGE_KF6FileMetadata option.  Right now it's a broken
but still available option, thus a bug.

(This was originally reported as breakage under BUG: 322922 as listed in the
original commit.  I'll cross-reference the bugs after submit.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.