FindwxWidgets.cmake: lack of options to find/select the right wxWidgets

[mojca (Mojca Miklavec)]

With respect to the ticket #37819 I'm having problems adapting plplot to use wxWidgets if wx-config isn't at default location.

I would like to be able to specify the path to ${prefix}/lib/wx/config/osx_cocoa-unicode-2.9 which should be enough to configure everything else related to wxWidgets, but I didn't spend enough time to dive deeper into the issue, also because plplot's CMake support is a bit suboptimal (I had serious problems using ccmake to configure it).

This is an upstream bug (I'm not sure which upstream though), but I would like to suggest to keep this ticket open until it's fixed upstream if possible.

The port plplot provides cmake/modules/FindwxWidgets.cmake which is very similar to the one shipped with cmake. So the ultimate point to patch this would probably be cmake and then ask plplot developer to fetch an up-to-date file from there.

Here's a ticket on the cmake bug tracker:

• ​http://public.kitware.com/Bug/view.php?id=11296

It's about a different issue, but it's probably related to the fact that the file lacks some features. Ideally a bug report should be sent to that tracker, possibly together with a patch.

A ticket on the wxWidgets' bug tracker has been closed as " not a wxWidgets bug":

• ​http://trac.wxwidgets.org/ticket/15199

even though it would probably be nice if wxWidgets would provide their own reference implementation of what they deem to be important for proper functionality like they do for aclocal/wxwin.m4 (that file could serve as a role model of what options are needed).

PS: feel free to change the summary line, I'm not sure how to best describe this.

[mojca (Mojca Miklavec)]

I'm removing plplot from the port list since plplot works in this respect for a while already, but it would still be nice to have FindwxWidgets.cmake with slightly more advanced functionality.

[mojca (Mojca Miklavec)]

I was also told that there could only be a single owner of the ticket, so I'm moving everyone from owner to "CC". There is not much MacPorts developers can do other than pushing the CMake developers to make the necessary change to offer more flexibility.

[mojca (Mojca Miklavec)]

I'm closing this ticket. Either upstream will implement this at some point in which case CMake will be upgraded automatically. Or the ticket will be left open forever.

It is not critical for our ports as there are workarounds / less elegant solutions.