wxWidgets: allow side-by-side installation of 2.8 and 2.9

[mojca (Mojca Miklavec)]

See also #26082 and #37819.

I believe that a trivial fix could make side-by-side installation of wxWidgets 2.8 and 2.9 possible and would allow easier testing and transition of wxWidgets dependent ports.

By looking at the files that wxWidgets 2.9.5 install, the only possibly conflicting files seem to be the following:

  /opt/local/bin/wx-config
  /opt/local/bin/wxrc
  /opt/local/share/aclocal/wxwin.m4
  /opt/local/share/bakefile/presets/wx.bkl
  /opt/local/share/bakefile/presets/wx_presets.py
  /opt/local/share/bakefile/presets/wx_unix.bkl
  /opt/local/share/bakefile/presets/wx_win32.bkl
  /opt/local/share/bakefile/presets/wx_xrc.bkl
  /opt/local/share/locale/*/LC_MESSAGES/wxstd.mo

These files are probably easy to move around (I didn't try, I only speculate). The first two binaries can be (de)activated with port_select (I managed to do that in my user's SVN), the localisation files have only been added to 2.9. The version 2.8 contains some documentation that has apparently been dropped in 2.9 and the only remaining conflicts then seem to be:

  /opt/local/share/aclocal/wxwin.m4
  /opt/local/share/bakefile/presets/wx.bkl
  /opt/local/share/bakefile/presets/wx_unix.bkl
  /opt/local/share/bakefile/presets/wx_win32.bkl

I would further suggest to delete wxWidgets26, to replace wxWidgets by wxWidgets28 and wxWidgets-devel by wxWidgets30 (which is already there).

Then something like "port select" (or "port install wxWidgets +wx30") would be needed to create those two symlinks in $prefix/bin. I don't believe that anything else is really needed except for maybe a very simple wxWidgets PortGroup to be able to set path like this:

--with-wx-config=${prefix}/bin/wx-config

or rather

--with-wx-config=${prefix}/lib/wx/config/osx_cocoa-unicode-2.9

and possibly some other trivial issues I'm not yet aware of.

Further on the ports should get variants +wxWidgets28, +wxWidgets30, but that's further down the road. I believe that making side-by-side installation of the two ports would be a huge step forward.

[cooljeanius (Eric Gallager)]

What should we recommend users do in the meantime while we still work this out?

[mojca (Mojca Miklavec)]

As long as maintainer cannot put together a solution, there's no way that users can do anything other than not installing any ports that require wxWidgets ;)

[mojca (Mojca Miklavec)]

I now tried to add

--datadir=${prefix}/share/${distname}/${version}

and the files end up in

  /opt/local/share/wxWidgets/2.9.5/aclocal/wxwin.m4
  /opt/local/share/wxWidgets/2.9.5/bakefile/presets/wx.bkl
  /opt/local/share/wxWidgets/2.9.5/bakefile/presets/wx_presets.py
  /opt/local/share/wxWidgets/2.9.5/bakefile/presets/wx_unix.bkl
  /opt/local/share/wxWidgets/2.9.5/bakefile/presets/wx_win32.bkl
  /opt/local/share/wxWidgets/2.9.5/bakefile/presets/wx_xrc.bkl
  /opt/local/share/wxWidgets/2.9.5/locale/*/LC_MESSAGES/wxstd.mo

Given that the locale is only present in 2.9, one could probably add

   --localedir=${prefix}/share/locale

and possibly install those files with port_select but that's debatable and less important given that almost no-one missed the localisation in 2.8. Debian installs localisation files as a separate package and maybe that's a way to go anyway, it's just that it's less important than the rest at the moment.

I'm more worried about the remaining aclocal and bakefiles. At least gnuplot compiles without any of these; I'm not yet sure about the rest of ports.

[mojca (Mojca Miklavec)]

See also #24350 about wxPython.

[mojca (Mojca Miklavec)]

Fixed in r110234.