Opened 10 years ago

Closed 10 years ago

Last modified 10 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 10 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 10 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:2 Changed 10 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 10 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 10 years ago by RJVB (René Bertin) (previous) (diff)

comment:4 Changed 10 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 10 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 10 years ago by NicosPavlov

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

comment:7 Changed 10 years ago by NicosPavlov

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