Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#44119 closed defect (fixed)

kdelibs4: remove FindFlex.cmake

Reported by: mojca (Mojca Miklavec) Owned by: NicosPavlov
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: cgilles (HumanDynamo), macports@…, RJVB (René Bertin)
Port: kdelibs4

Description

Please remove FindFlex.cmake from kdelibs4, test if it still works after removal and also ask the upstream for a fix. Apparently a better version is part of CMake already.

See comment:10:ticket:44104.

Change History (7)

comment:1 in reply to:  description Changed 5 years ago by RJVB (René Bertin)

Also see comment:ticket:44104:14 : reinstalling cmake fixes the issue, so a simple kdelibs patch that removes FindFLEX.cmake (say from destroot) should resolve the issue locally.

I'm not sure about requesting an upstream fix. I just checked on my (K)Ubuntu rig; /usr/share/cmake-2.8/Modules/FindFLEX.cmake is part of the cmake-data package, whereas kdelibs5-dev package installs a file /usr/share/kde4/apps/cmake/modules/FindFlex.cmake . Having noticed that, I see that the MacPorts kdelibs4 port installs a file /opt/local/share/apps/cmake/modules/FindFlex.cmake. I'm a bit at a loss why the solution I suggested in the other ticket worked, but at least I understand why I never had a problem: my /opt/local points to a tree on a case-sensitive partition.

So I think that the only thing that can be done upstream is asking why they provide their own version of this file. If there's a good reason, MacPorts will have to find a workaround if they wish to continue to support case-insensitive filesystems. I'm not 100% sure, but I have a hunch that cmake might well impose certain rules on cmake filenames, and in that case there isn't much choice that will disambiguate FindFLEX and FindFlex after case-folding.

Last edited 5 years ago by ryandesign (Ryan Schmidt) (previous) (diff)

comment:2 Changed 5 years ago by mojca (Mojca Miklavec)

The main question is: why does kdelibs4 even need its own FindFlex.cmake if it's already part of CMake?

comment:3 Changed 5 years ago by RJVB (René Bertin)

Yep. Unless there's more than a single way to query cmake about the presence of flex, in which case there is maybe a solution to be found there? Note that case-related filename aliasing will also occur on MS Windows where it's much harder to avoid.

Do we know if kdelibs always provided its own FindFlex.cmake or if it's a recent addition?

So who's going to ask it upstream - the port maintainer (and which port, kdelibs4 or digikam since that's the only one we know to be affected)?

Last edited 5 years ago by RJVB (René Bertin) (previous) (diff)

comment:4 Changed 5 years ago by mojca (Mojca Miklavec)

We need to ask kdelibs4 developers. Digikam has nothing to do with this problem (unless – I didn't check – it uses the wrong version of Flex vs. FLEX). Anyone can submit a bug report, but I'm not even using any of that software, so I would prefer if someone else would do it.

The maintainer needs to make sure that the file is removed in MacPorts (whether or not the upstream changes anything).

comment:5 Changed 5 years ago by NicosPavlov

I'll make the commit later today. For reference, when looking at the two folders, I found at least the files below which are installed both by cmake and kdelibs4, usually with a difference in capitals.

FindAlsa.cmake
FindFlex.cmake
FindGettext.cmake
FindLibLZMA.cmake
FindLibXslt.cmake
FindRUBY.cmake

I did not look up if they are identical or not, but several of them should be working, as they should be used by low-level ports during the configure stage.

comment:6 Changed 5 years ago by NicosPavlov

Committed in r121377. I will report the issue upstream later.

comment:7 Changed 5 years ago by NicosPavlov

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.