From: Henry L. <hen...@nt...> - 2012-06-14 09:45:29
|
To hopefully avoid an unnecessary detour today: Installing wxHAskell 0.9 with wxWidgets 2.9.3 in Mac OS 10.6.8. Before I build and install the wxWidgets lib locally: I note the WxHAskell/Mac instructions (in step 3) insist the older pre-installed widgets should not be found in /usr/bin, and the proposed configuration parameters (in step 2) put the widgets in /usr/local/, but I am slightly reluctant to mess about with the original installed version if possible. Is the wx install indiscriminate in its choice of widgets library version, and will just try to go with the first one it finds, or will it search for an appropriate compatible version? I was hoping to either do something like cabal install wx cabal-macosx --extra-lib-dirs=<PATH TO MY LOCAL WIDGETS 2.9 LIB DIR> OR to add the local widgets lib dir onto $PATH (in paths.d for example) where it would be searched after /usr/bin (I believe). (+ I presume this is also what would happen if I just installed in /usr/local as per the instructions, without also removing the old widgets, and presumably 'which wx-config' will still find the old one first in this case) Will this approach not/work OK? TIA / Henry |
From: Henry L. <hen...@nt...> - 2012-06-19 16:05:05
|
Hi Jeremy + ALL On 17 Jun 2012, at 11:55, Jeremy O'Donoghue wrote: > Hi Henry, > > On 14 June 2012 10:45, Henry Lockyer <hen...@nt...> wrote: > . . . > Installing wxHAskell 0.9 with wxWidgets 2.9.3 in Mac OS 10.6.8. > . . .I am slightly reluctant to mess about with the original installed version if possible. . . > > The recommended approach to dealing with more than one wxWidgets install is to set the WXWIN environment variable to point to your preferred wxWidgets installation, and WX_CFG to point to the preferred build, e.g. WXWIN=/usr/local. You only need WX_CFG if you have e.g. debug and release build variants. I must confess I didn't really understand how this should help, but I tried it anyway, and it does not seem to make any obvious difference. At least as I have done it. I set WXWIN to point to the root dir of my 2.9.3 build as instructed on http://wiki.wxwidgets.org/Setting_Environment_Variable_For_XCode as this is the only advice I could find wrt to using WXWIN on unix, though I suppose this is really to facilitate Xcode-based widgets-related development and not sure it's relevant. I checked it was set (using "set") then reran the cabal install attempt, but I just get the same failure response. As I see it, cabal install of wx etc. is using wx-config, which should not be the pre-installed one in /usr/bin (as highlighted in the WxHaskell/Mac wiki page) - or at least it should respond to confirm 2.9 is available ok in the place/s it knows about. So when I previously tried simply putting my 2.9.3 lib dir as an additional lib path to cabal it did not work, and with or without this I always get the response below due to it finding the old 2.8 version. So wx-config does not appear to take any notice of WXWIN. (or?) "Configuring wxc-0.90.0.3... Warning: No config found to match: /usr/bin/wx-config --version=2.9 --version-full in /usr/lib/wx/config If you require this configuration, please install the desired library build. If this is part of an automated configuration test and no other errors occur, you may safely ignore it. You may use wx-config --list to see all configs available in the default prefix. setup: failed" The wxWidgets online book, appendix B, does not suggest any 'standard' use of WXWIN on unix type systems. "On Windows After you’ve built wxWidgets, you should create an environment variable named WXWIN and set it to the home folder of your wxWidgets source tree. (If you use the command line to build, you can also set or override WXWIN at build time by passing it in as an option to your makefile.) On Unix and Mac OS X In a standard install, you need not do anything as long as wx-config is on your PATH. wx-config is all you need; see “Using wx-config” later in this appendix." etc. Looking at the wxwidgets wiki wx-config page I saw the brief comment: On Unix systems, wx-config may be a symlink to specific wx-config files for various wxWidgets ports/platforms (wxbase-2.5-config, wxgtk-2.5-config, ...). This is not terribly clear but I think it is suggesting that the wx-config in the path could be a symlink which you edit 'manually' to point to a different wx-config in another widgets directory when you want to change to use a different build (or set of builds) in another install location. (Anyone got a better/different interpretation?) I don't really understand the dylib linking process but I am supposing that wx-config is only implicated at link time, so it only needs to find the right wxWidgets at this time and things will continue to work afterwards once they are linked, regardless of where the wx-config and lib files were located - right???? Evidently wx-config will support multiple builds, but this seem to require them all to have been built in the same root widgets build location. So I plan to do something like the symlink idea, or I may just temporarily rename the old 2.8 wx-config and add my new local 2.9 directory to the end of the path list. This is the new plan, though it seems a bit messy. Anyone out there see any problems with this ? TIA / Henry PS. I saw some interesting work around this topic in the wxHaskell-developers list in the thread eg. at http://www.mail-archive.com/wxh...@li.../msg00751.html for Lion, but it is beyond my current level of detail to be able to apply it, and I'm not sure if it is up to date or any of it is useable as-is. Frustratingly it seems to be addressing the QuickTime issue too! (though maybe it is just for 32bit, I forget) and there may even be a 'brew' including the changes. Unfortunately when I looked into homebrew I was put off using it as it wants to take over /usr/local (or at least it says using another directory is 'at your peril') and I have other stuff already sitting in there that I equally don't want to imperil (though the information about the level of peril seems conflicting). |