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 
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/wxhaskell-devel@lists.sourceforge.net/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). 

------------------------------------------------------------------------------
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 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
wxhaskell-users mailing list
wxhaskell-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

Reply via email to