Hi Jeremy + ALL
On 17 Jun 2012, at 11:55, Jeremy O'Donoghue wrote:
> Hi Henry,
> On 14 June 2012 10:45, Henry Lockyer <henry.lock...@ntlworld.com> 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
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?)
Warning: No config found to match: /usr/bin/wx-config --version=2.9
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.
The wxWidgets online book, appendix B, does not suggest any 'standard' use of
WXWIN on unix type systems.
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."
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
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 -
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
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
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
wxhaskell-users mailing list