[wxhaskell-devel] build conflicts

[David Duke]

On linux

The Glorious Glasgow Haskell Compilation System, version 8.6.5

compiled using version 2.4.0.1 of the Cabal library
1.3.6.1-BYFFNcZJFE8A61mvswaSZH) requires time-1.8.0.2
wxdirect would not istall via cabal. Downloading the archive to dig deeper
and running configure  I get

This package indirectly depends on multiple versions of the same package.
This is very likely to cause a compile failure.
  package text (text-1.2.4.0-2ioOlD8VDXvIdRjkn7jQ2N) requires
array-0.5.3.0
  package deepseq (deepseq-1.4.4.0) requires array-0.5.3.0
  package containers (containers-0.6.2.1-ChagGP7vch8FhOClSM0wYR)
requires array-0.5.3.0
  package binary (binary-0.8.8.0-xIsyONPiRj4PHS6QH94MI) requires
array-0.5.3.0
  package strict (strict-0.3.2-DP5FvAMlpD7YzHTh3a9B7) requires
array-0.5.4.0-JTWuK1N2qV6Hp4ahtyDNgH
  package wxdirect (wxdirect-0.92.3.0) requires
time-1.10-BMxqFVrI4CvBhqQD8eT7Hn
  package unix (unix-2.7.2.2-41NgTOCE07rBsn9g3jmFpU) requires
time-1.8.0.2
  package directory (directory-

Trying stack I get



ownloading lts-15.12 build plan ...
RedownloadFailed Request {
  host = "raw.githubusercontent.com"
  port = 443
  secure   = True
  requestHeaders   = []
  path = "/fpco/lts-haskell/master//lts-15.12.yaml"
  queryString  = ""
  method   = "GET"
  proxy= Nothing
  rawBody  = False
  redirectCount= 10
  responseTimeout  = ResponseTimeoutDefault
  requestVersion   = HTTP/1.1
}
 "/home/david/.stack/build-plan/lts-15.12.yaml" (Response {responseStatus =
Status {statusCode = 404, statusMessage = "Not Found"}, responseVersion =
HTTP/1.1, responseHeaders =
[("Connection","keep-alive"),("Content-Length","14"),("Content-Security-Policy","default-src
'none'; style-src 'unsafe-inline';
sandbox"),("Strict-Transport-Security","max-age=31536000"),("X-Content-Type-Options","nosniff"),("X-Frame-Options","deny"),("X-XSS-Protection","1;
mode=block"),("Content-Type","text/plain; charset=utf-8"),("Via","1.1
varnish
(Varnish/6.0)"),("X-GitHub-Request-Id","A8D4:1A3F:13F0C3:19BC81:5ECA74A9"),("Accept-Ranges","bytes"),("Date","Sun,
24 May 2020 13:20:41 GMT"),("Via","1.1
varnish"),("X-Served-By","cache-lcy19231-LCY"),("X-Cache","MISS,
MISS"),("X-Cache-Hits","0,
0"),("X-Timer","S1590326442.608777,VS0,VE141"),("Vary","Authorization,Accept-Encoding"),("Access-Control-Allow-Origin","*"),("X-Fastly-Request-ID","e5f67693e6e9712aa133e0d0a45c394e52c7e305"),("Expires","Sun,
24 May 2020 13:25:41 GMT"),("Source-Age","0")], responseBody = (),
responseCookieJar = CJ {expose = []}, responseClose' = ResponseClose})



Can anyone decode this for me? Do I have any chance of getting a working wx
or should I abandon all hope?

thanks,
David
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] Build failure

[M. Schulte]

Hi,

> it seems that the problem lies with wxc. I (for now) have provided
> bin/mk-cabal to build locally, did you use that, what is the full
> build output, in particular w.r.t wxc?

Yes, I have used bin/mk-cabal. The full build output is here:
http://pastebin.com/XSgGDh9E (Atze, nevermind my last mail -- I
decided to simply upload the log at pastebin. :)

> wxc build (e.g.) might fail because of an incorrect/incomplete
> install of wxWidgets. Is the correct (and not an old) wx-config
> used, mine by default is installed in /usr/local/bin/wx-config.

The wxWidgets 2.9.5 (with GTK backend) installed in ~/local is the
only one I have installed on the system.

Thanks!
melanie

--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] Build failure

[Atze Dijkstra]

Hi Melanie,

it seems that the problem lies with wxc. I (for now) have provided bin/mk-cabal 
to build locally, did you use that, what is the full build output, in 
particular w.r.t wxc? wxc build (e.g.) might fail because of an 
incorrect/incomplete install of wxWidgets. Is the correct (and not an old) 
wx-config used, mine by default is installed in /usr/local/bin/wx-config.

Atze

On  2 Aug, 2013, at 11:01 , "M. Schulte"  wrote:

> Hi,
> 
> thanks for your quick help, Atze.
> 
>> this problem is fixed in the forked repo
>> https://github.com/atzedijkstra/wxHaskell. See the README there. The
>> intent is that this fork will merge back into the official repo and
>> an update of the version available via cabal and Hackage.
> 
> I have installed wxWidgets 2.9.5 in ~/local. When I run bin/mk-cabal
> inside the local checkout of the repository
> https://github.com/wxHaskell/wxHaskell (as I understood from your
> other e-mail), the following build failure is triggered:
> 
>  [...]
>  generated 1488 methods for 124 classes.
>  generating: src/haskell/Graphics/UI/WXCore/WxcClassesMZ.hs
>  generated 2340 methods for 129 classes.
>  generating: src/haskell/Graphics/UI/WXCore/WxcClasses.hs
>  generated 3828 total methods for 253 total classes.
>  ok.
>  setup: Missing dependency on a foreign library:
>  * Missing C library: wxc
>  This problem can usually be solved by installing the system package that
>  provides this library (you may need the "-dev" version). If the library is
>  already installed but in a non-standard location then you can use the flags
>  --extra-include-dirs= and --extra-lib-dirs= to specify where it is.
>  cabal: Error: some packages failed to install:
>  wxcore-0.90.1.0 failed during the configure step. The exception was:
>  ExitFailure 1
>  Resolving dependencies...
>  Configuring wx-0.90.1.0...
>  cabal: At least the following dependencies are missing:
>  wxcore >=0.90.1.0
>  Resolving dependencies...
>  cabal: Could not resolve dependencies:
> 
> I have ghc 7.4.1 and haskell-platform 2012.2.0.0.
> Any help appreciated. :)
> 
> Thanks,
> mel


- Atze -

Atze Dijkstra, Department of Information and Computing Sciences. /|\
Utrecht University, PO Box 80089, 3508 TB Utrecht, Netherlands. / | \
Tel.: +31-30-2534118/1454 | WWW  : http://www.cs.uu.nl/~atze . /--|  \
Fax : +31-30-2513971  | Email: a...@uu.nl ... /   |___\




--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] Build failure

[M. Schulte]

Hi,

thanks for your quick help, Atze.

> this problem is fixed in the forked repo
> https://github.com/atzedijkstra/wxHaskell. See the README there. The
> intent is that this fork will merge back into the official repo and
> an update of the version available via cabal and Hackage.

I have installed wxWidgets 2.9.5 in ~/local. When I run bin/mk-cabal
inside the local checkout of the repository
https://github.com/wxHaskell/wxHaskell (as I understood from your
other e-mail), the following build failure is triggered:

[...]
generated 1488 methods for 124 classes.
generating: src/haskell/Graphics/UI/WXCore/WxcClassesMZ.hs
generated 2340 methods for 129 classes.
generating: src/haskell/Graphics/UI/WXCore/WxcClasses.hs
generated 3828 total methods for 253 total classes.
ok.
setup: Missing dependency on a foreign library:
* Missing C library: wxc
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
cabal: Error: some packages failed to install:
wxcore-0.90.1.0 failed during the configure step. The exception was:
ExitFailure 1
Resolving dependencies...
Configuring wx-0.90.1.0...
cabal: At least the following dependencies are missing:
wxcore >=0.90.1.0
Resolving dependencies...
cabal: Could not resolve dependencies:

I have ghc 7.4.1 and haskell-platform 2012.2.0.0.
Any help appreciated. :)

Thanks,
mel

--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] Build failure

[Atze Dijkstra]

Hi Melanie,

this problem is fixed in the forked repo 
https://github.com/atzedijkstra/wxHaskell. See the README there. The intent is 
that this fork will merge back into the official repo and an update of the 
version available via cabal and Hackage.

regards,

On  2 Aug, 2013, at 01:19 , "M. Schulte"  wrote:

> Hi,
> 
> I'm on Fedora 18, having installed wxWidgets (GTK) 2.9 in ~/local, ~/local/bin
> is in $PATH. When I do 'cabal install wx', the following error gets triggered:
> 
> [...]
> /usr/bin/gcc -Wl,--hash-size=31 -Wl,--reduce-memory-overheads -Isrc/include 
> -I/home/mel/local/include/wx-2.9 
> -I/home/mel/local/lib/wx/include/gtk2-unicode-2.9 -D__WXGTK__ -DWXUSINGDLL 
> -D_FILE_OFFSET_BITS=64 -DwxcREFUSE_MEDIACTRL -fPIC -c src/cpp/eljgrid.cpp -o 
> dist/build/src/cpp/eljgrid.o
> src/cpp/eljgrid.cpp: In function ‘void 
> wxGridCellEditor_PaintBackground(wxGridCellEditor*, int, int, int, int, 
> void*)’:
> src/cpp/eljgrid.cpp:61:65: error: no matching function for call to 
> ‘wxGridCellEditor::PaintBackground(wxRect, wxGridCellAttr*)’
> src/cpp/eljgrid.cpp:61:65: note: candidate is:
> In file included from /home/mel/local/include/wx-2.9/wx/grid.h:15:0,
> from src/include/wrapper.h:32,
> from src/cpp/eljgrid.cpp:1:
> /home/mel/local/include/wx-2.9/wx/generic/grid.h:216:18: note: virtual void 
> wxGridCellEditor::PaintBackground(wxDC&, const wxRect&, const wxGridCellAttr&)
> /home/mel/local/include/wx-2.9/wx/generic/grid.h:216:18: note:   candidate 
> expects 3 arguments, 2 provided
> src/cpp/eljgrid.cpp: In function ‘bool wxGrid_CanDragRowSize(wxGrid*)’:
> src/cpp/eljgrid.cpp:741:30: warning: ‘bool wxGrid::CanDragRowSize() const’ is 
> deprecated (declared at 
> /home/mel/local/include/wx-2.9/wx/generic/grid.h:1836) 
> [-Wdeprecated-declarations]
> src/cpp/eljgrid.cpp: In function ‘bool wxGrid_CanDragColSize(wxGrid*)’:
> src/cpp/eljgrid.cpp:756:30: warning: ‘bool wxGrid::CanDragColSize() const’ is 
> deprecated (declared at 
> /home/mel/local/include/wx-2.9/wx/generic/grid.h:1837) 
> [-Wdeprecated-declarations]
> cabal: Error: some packages failed to install:
> wx-0.90.0.1 depends on wxc-0.90.0.4 which failed to install.
> wxc-0.90.0.4 failed during the building phase. The exception was:
> ExitFailure 1
> wxcore-0.90.0.3 depends on wxc-0.90.0.4 which failed to install.
> [mel@lily ~]$
> 
> Any idea, what's going on here?
> 
> Thanks,
> melanie--
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent 
> caught up. So what steps can you take to put your SQL databases under 
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk___
> wxhaskell-devel mailing list
> wxhaskell-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


- Atze -

Atze Dijkstra, Department of Information and Computing Sciences. /|\
Utrecht University, PO Box 80089, 3508 TB Utrecht, Netherlands. / | \
Tel.: +31-30-2534118/1454 | WWW  : http://www.cs.uu.nl/~atze . /--|  \
Fax : +31-30-2513971  | Email: a...@uu.nl ... /   |___\




--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

[wxhaskell-devel] Build failure

[M. Schulte]

Hi,

I'm on Fedora 18, having installed wxWidgets (GTK) 2.9 in ~/local, ~/local/bin
is in $PATH. When I do 'cabal install wx', the following error gets triggered:

[...]
/usr/bin/gcc -Wl,--hash-size=31 -Wl,--reduce-memory-overheads -Isrc/include 
-I/home/mel/local/include/wx-2.9 
-I/home/mel/local/lib/wx/include/gtk2-unicode-2.9 -D__WXGTK__ -DWXUSINGDLL 
-D_FILE_OFFSET_BITS=64 -DwxcREFUSE_MEDIACTRL -fPIC -c src/cpp/eljgrid.cpp -o 
dist/build/src/cpp/eljgrid.o
src/cpp/eljgrid.cpp: In function ‘void 
wxGridCellEditor_PaintBackground(wxGridCellEditor*, int, int, int, int, void*)’:
src/cpp/eljgrid.cpp:61:65: error: no matching function for call to 
‘wxGridCellEditor::PaintBackground(wxRect, wxGridCellAttr*)’
src/cpp/eljgrid.cpp:61:65: note: candidate is:
In file included from /home/mel/local/include/wx-2.9/wx/grid.h:15:0,
 from src/include/wrapper.h:32,
 from src/cpp/eljgrid.cpp:1:
/home/mel/local/include/wx-2.9/wx/generic/grid.h:216:18: note: virtual void 
wxGridCellEditor::PaintBackground(wxDC&, const wxRect&, const wxGridCellAttr&)
/home/mel/local/include/wx-2.9/wx/generic/grid.h:216:18: note:   candidate 
expects 3 arguments, 2 provided
src/cpp/eljgrid.cpp: In function ‘bool wxGrid_CanDragRowSize(wxGrid*)’:
src/cpp/eljgrid.cpp:741:30: warning: ‘bool wxGrid::CanDragRowSize() const’ is 
deprecated (declared at /home/mel/local/include/wx-2.9/wx/generic/grid.h:1836) 
[-Wdeprecated-declarations]
src/cpp/eljgrid.cpp: In function ‘bool wxGrid_CanDragColSize(wxGrid*)’:
src/cpp/eljgrid.cpp:756:30: warning: ‘bool wxGrid::CanDragColSize() const’ is 
deprecated (declared at /home/mel/local/include/wx-2.9/wx/generic/grid.h:1837) 
[-Wdeprecated-declarations]
cabal: Error: some packages failed to install:
wx-0.90.0.1 depends on wxc-0.90.0.4 which failed to install.
wxc-0.90.0.4 failed during the building phase. The exception was:
ExitFailure 1
wxcore-0.90.0.3 depends on wxc-0.90.0.4 which failed to install.
[mel@lily ~]$

Any idea, what's going on here?

Thanks,
melanie--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] Build

[harry]

Eric Kow  writes:

> >PATH: (add these)
> > %WXWIN%\lib\gcc_dll;%WXWIN%;%CABAL_DIR%\wxc-%WXC_VERSION%\%GHC_VERSION%

> So by rights, as far as building wxHaskell and wxHaskell apps is concerned
(sandbox or no), we need
> “only” really set the WXWIN and WXCFG environment variables.  I forget
what exactly for, partly to
> grab the complicated set of compiler flags needed to import and link
against the wxWidgets libraries.

OK, so the last component which gets added to the path:
%CABAL_DIR%\wxc-%WXC_VERSION%\%GHC_VERSION%
That looks like something which really shouldn't be there, what exactly is
it used for? Also, is WXWIN used during the build process, as well as when
updating the path?


--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] Build

[Eric Kow]

On 2 Jun 2013, at 08:44, harry wrote:

> Referring to the installation instructions, we have the following
> environment variables:
> 
>CABAL_DIR: C:\Users\XXX\AppData\Roaming\cabal (Windows XP: C:\Documents
> and Settings\XXX\Application Data\cabal, or: %APPDATA%\cabal)
>GHC_VERSION: 7.0.3 (for our convenience)
>WXC_VERSION: 0.90.0.2
>WXWIN: C:\wxWidgets-2.9.3
>WXCFG: gcc_dll\mswu
>PATH: (add these)
> %WXWIN%\lib\gcc_dll;%WXWIN%;%CABAL_DIR%\wxc-%WXC_VERSION%\%GHC_VERSION%
> 
> It may be worth considering how all these are used. In particular, are
> GHC_VERSION, WXC_VERSION, WXWIN and CABAL_DIR only used for setting the path?

I think that these indeed are only used for convenience, so we're down to three 
environment variables:

• WXWIN (used by wxc on compile time
• WXCFG: (used by wxc on compile time)
• PATH: (add these) (needed on runtime so we can find wxWidgets and wxC 
respectively)

So by rights, as far as building wxHaskell and wxHaskell apps is concerned 
(sandbox or no), we need “only” really set the WXWIN and WXCFG environment 
variables.  I forget what exactly for, partly to grab the complicated set of 
compiler flags needed to import and link against the wxWidgets libraries.

-- 
Eric Kow 


--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] Build

[harry]

Referring to the installation instructions, we have the following
environment variables:

CABAL_DIR: C:\Users\XXX\AppData\Roaming\cabal (Windows XP: C:\Documents
and Settings\XXX\Application Data\cabal, or: %APPDATA%\cabal)
GHC_VERSION: 7.0.3 (for our convenience)
WXC_VERSION: 0.90.0.2
WXWIN: C:\wxWidgets-2.9.3
WXCFG: gcc_dll\mswu
PATH: (add these)
%WXWIN%\lib\gcc_dll;%WXWIN%;%CABAL_DIR%\wxc-%WXC_VERSION%\%GHC_VERSION%

It may be worth considering how all these are used. In particular, are
GHC_VERSION, WXC_VERSION, WXWIN and CABAL_DIR only used for setting the path?


--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] Build

[Eric Kow]

On 2 Jun 2013, at 07:56, harry wrote:
> The next hurdle is wxcore, which expects to find various bits of wxc in
> places that it should really be keeping its nose out of. I suspect that if
> everything has been set up correctly outsides of the sandbox, this too will
> succeed by following the environment variables (as long as there aren't any
> spaces on the path), but I can't actually test this hypothesis because I've
> upgraded my HP, and wxc/ore won't compile on GHC 7.6.


OK, so I think maybe we should pick this back up when the wxHaskell team have 
had a chance to catch up with GHC 7.6, because I used wxHaskell in a sandbox 
(albeit on MacOS X), and have reason to believe that having wxdirect be 
available on the PATH addresses this pain point.

If Blair is still interested in wxHaskell jobs, this is another great one that 
needs help.

Thanks,

-- 
Eric Kow 


--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] Build

[harry]

Eric Kow  writes:

> OK let me get this straight.  Is the user-facing problem here that
installing wxHaskell for use in a sandbox
> environment is impossible or just very inconvenient/difficult?

The problem is that cabal-dev tries to install all the dependencies
automatically. So if I have a dependency on wx, cabal-dev goes all the way
back to wxdirect and tries to install it. This succeeds, but is useless,
because the executable won't be found later. It then installs wxc, which I
think will succeed if wxdirect has already been installed outside of the
sandbox, and can therefore be found on the path.

The next hurdle is wxcore, which expects to find various bits of wxc in
places that it should really be keeping its nose out of. I suspect that if
everything has been set up correctly outsides of the sandbox, this too will
succeed by following the environment variables (as long as there aren't any
spaces on the path), but I can't actually test this hypothesis because I've
upgraded my HP, and wxc/ore won't compile on GHC 7.6.


--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] Build

[Howard B. Golden]

On 06/01/2013 01:34 PM, Eric Kow wrote:

> I had some longer comments on the technical issues.  I think we may
> be need to step back a bit and peel apart the fundamental issues
> first (C++, shared libraries, other?) but first let's make sure we
> understand what the user-facing problem really is.  Is it
> impossibility or is it hoops?

While you are thinking about this, I hope you will also expand your
discussion to the Haskell Platform use case: what would it take to
develop a binary add-on that would install wxhaskell on top of a binary
HP installation? Extra credit for doing this on Linux, Windows and OS X.

In the earlier discussion you mentioned wxc and how it was hand
generated. I wonder if the swig tool could be adapted to work with
Haskell. This has been discussed for many years. Recently there was a
GSoC project to make swig generate a C interface from C++. If this
addition to swig is usable, it may be worth trying it to autogenerate
wxc or a major part of it.

While I use Linux at home and am comfortable building software from
source, I think it would be a big win for the Haskell community to have
wxhaskell (and gtk2hs) binary packages that run on Windows and OS X
since these platforms are used more.

Howard

--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] Build

[Eric Kow]

OK, so let's step back a bit.

I think Luc's right in two senses, first that we need to understand what the 
user-facing problem is, and second what is technical problem lying at the heart 
of user-facing problem.

In your first message you said:

> OTOH, cabal install wxdirect installs both the helper executable and a
> library. 3 other packages then have to be installed, at least one of which
> requires environment variables pointing to bits of earlier packages. One
> upshot of all this is that it's well nigh impossible to use wxhaskell with
> cabal-dev, whereas with gtk2hs it's really easy (install gtk2hs-buildtools
> outside the sandbox, then gtk will use it in the sandbox).

OK let me get this straight.  Is the user-facing problem here that installing 
wxHaskell for use in a sandbox environment is impossible or just very 
inconvenient/difficult?

My understanding is that it's the latter: namely because you have to jump 
through three extra hoops:

w0. install wxWidgets
w1. update PATH to point to wxWidgets?
w2. install wx-config
w3. set up WXWIN, WXWIN, PATH environment variables
w4. install wxdirect
w5. then cabal install wx (which grabs wxcore and wxc automatically)

Contrast with four steps in gtk2hs

g0. install gtk
g1. update PATH to point to gtk?
g2. install gtk2hs-buildtool
g3. cabal install gtk

Do I have this right, first of all?

I had some longer comments on the technical issues.  I think we may be need to 
step back a bit and peel apart the fundamental issues first (C++, shared 
libraries, other?) but first let's make sure we understand what the user-facing 
problem really is.  Is it impossibility or is it hoops?

-- 
Eric Kow 


--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] Build

[harry]

Eric Kow  writes:

> May I ask which environment variables in particular you're referring to?

All of them, particularly those used to find the location of wxc. cabal-dev
installs all dependencies blindly, and doesn't know to set environment
variables.

> (B) [an aspiring wxHaskell hacker] modify wxcore's Setup.hs to use
> wxdirect as a library of some sort.  There's a bit of a complication
> here in that we're actually faking the dependency on wxdirect: we're
> claiming that wxcore depends on wxdirect when the case is more that
> the Setup.hs script used by wxcore uses wxdirect.

Removing this fake dependency would certainly help (also from wxc and
wxcore), because it messes up cabal-dev.

> - wxc (the C interface)

If I've understood you correctly, wxc doesn't install any Haskell libraries.
In which case, could it just create an executable that knows how to generate
the C wrapper? wxcore could then run it during setup, and finding it
wouldn't be a problem - cabal's bin directory is already on the path.

This might also make things easier for users of other languages wanting to
share wxc, as only template maniacs expect programs to do their work at
compile time :-)

My "vision", which may be fatally flawed for not understanding C, C++,
WxWidgets, or the WxHaskell build process, is:

 - cabal install wx-buildtools will install wxdirect (is this really needed
as a standalone executable?), and wxc, a program which knows how to create
the C wrappers. It will not install any libraries.

 - cabal install wxcore will run wxc to create the C wrappers, and put them
wherever it wants. It will not declare a dependency on wx-buildtools.

 - cabal install wx at it exist now.


--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] Build

[Eric Kow]

OK, I'm studying
  http://www.haskell.org/haskellwiki/WxHaskell/Windows
to update my understanding of the build infrastructure a bit

May I ask which environment variables in particular you're referring to?

So for the matter of executables not being on the path, two approaches might be

(A1) [the frustrated sandboxer] cabal-dev install wxdirect before
cabal-dev install your-package. Whilst this would install wxdirect
into your sandbox, with at least some versions of cabal-install, it
also creates symlinks pointing from ~/.cabal/bin into said sandbox
[fact-check?]

(A2) [the frustrated sandboxer] like with gtk2hs, install wxdirect
universally [I think this is what I do?]

(B) [an aspiring wxHaskell hacker] modify wxcore's Setup.hs to use
wxdirect as a library of some sort.  There's a bit of a complication
here in that we're actually faking the dependency on wxdirect: we're
claiming that wxcore depends on wxdirect when the case is more that
the Setup.hs script used by wxcore uses wxdirect.  There might be some
unpredictable cabalisation problems that arise due to the current
limitation I pointed to earlier

https://github.com/haskell/cabal/issues/948

---


So we have:
- wxWidgets C++
- wxc (the C interface)
- wxcore (autogenerated Haskell [FFI stuff] + low-ish level Haskell
calling the FFI stuff)
- wx (nicer Haskell)

In the case of wxc what we have are a bunch of C++ files that expose a
C interface to wxWidgets.  No fancy code generation, no Haskell.  Sure
there are folks who would love for wxc to be completely automatically
generated (as would I), but nobody has gotten around to it.  The wxc
build script needs to know where WxWidgets lives so that it knows what
libraries to link against (it calls the wx-config program for this,
which alas doesn't really exist on Windows and you have to very
painfully fetch a stand-in for), hence WXWIN

The autogenerated parts of wxcore are I think Haskell wrappers around
wxc [created by wxdirect].  The input to this process is just the
handwritten wxc header files, which wxcore Setup finds by asking
Cabal:

   https://github.com/atzedijkstra/wxHaskell/blob/master/wxcore/Setup.hs#L37

I notice that the wiki mentions WXC_VERSION and putting something like
%CABAL_DIR%\wxc-%WXC_VERSION%\%GHC_VERSION% in the PATH. Yuck. This
should “only” be needed when we actually want to run something, so
that the Windows runtime linking stuff can do its magic with wxc.dll

Once upon a time wxc/wxcore were a single package.  And we relatively
recently split them apart (I think to some rejoicing?) which made the
wxcore build process a lot simpler (?).  I'm afraid I'm going to have
to put this down now so I can't research our decision to make the
split, but I'd encourage anybody who wants to work on wxHaskell to
study the evolution of this.

Sorry for the mess folks!  I think the build situation has improved a
lot over the years.  But we still have a way to go.  I agree that
fewer hoops and a one-shot install are important.

Phew, hope this was useful.  Hopefully I didn't get things wrong in my
depiction above.  I think my ideal situation would be for something
like wxc to be shipped by default with wxWidgets and for a bunch of
exotic languages to use the same layer.  If you can make *that* happen
by coordinating with various language teams like wxOCaml and with the
wxWidgets folks, that'd be super.  But it's a sort of long-term thing…
(and may get bogged down by people hating the fact that wxc is
handwritten when it can so clearly be autogenerated, but then nobody
doing anything about it so it just gets stuck).  So maybe the right
thing to work on there is autogenerated wxc ;-)

Eric


On 31 May 2013 16:31, harry  wrote:
> Eric Kow  writes:
>
>> Is the issue something related to the wxdirect executable not being
>> available in the sandbox environment?
>
> Yes - executables built in cabal-dev aren't on the path (which is different
> for each sandbox). If wxdirect only built an executable, I could install it
> outside of the sandboxes, and it would be available in the path for later use.
>
> A similar issue arises with wxc - what exactly is it building, and why is an
> environment variable needed to find it later? Is it creating a Haskell
> library, or just creating come C files for use by wxcore?
>
>
> --
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> ___
> wxhaskell-devel mailing list
> wxhaskell-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel



-- 
Eric Kow 

--
Get 100% visibility into Java/

Re: [wxhaskell-devel] Build

[harry]

Eric Kow  writes:

> Is the issue something related to the wxdirect executable not being
> available in the sandbox environment?

Yes - executables built in cabal-dev aren't on the path (which is different
for each sandbox). If wxdirect only built an executable, I could install it
outside of the sandboxes, and it would be available in the path for later use.

A similar issue arises with wxc - what exactly is it building, and why is an
environment variable needed to find it later? Is it creating a Haskell
library, or just creating come C files for use by wxcore?


--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] Build

[Luc Taesch]

btw, we are already at the solution stage,  
what is the problem in fact ? what are the typical difficulties that a raise 
when installing wx ?
is it on the C side or on the haskell side ?  
is it because they have to be fetched separately ?  

do we have a shared view on where lies the problems ?  

--  
Luc Taesch
Envoyé avec Sparrow (http://www.sparrowmailapp.com/?sig)


Le vendredi 31 mai 2013 à 15:24, Eric Kow a écrit :

> On 31 May 2013 06:34, harry  (mailto:volderm...@hotmail.com)> wrote:
> > The first problem is that wxdirect installs both executables and a library -
> > why is that necessary, and is there another way to do it?
> >  
>  
>  
> Could you elaborate on this? I'm not 100% sure I follow.
>  
> Is the issue something related to the wxdirect executable not being
> available in the sandbox environment?
>  
> One issue is that wxdirect is used in the build process of the wxcore Setup.hs
>  
> One thing which I think might help matters is if we had a way for the
> custom Setup.hs in wxcore to depend on wxdirect. Now one option would
> be for us to just swallow wxdirect directly into wxcore, making it
> part of the setup script. There's no particular reason it has to be
> run as an executable.
>  
> If not feasible, then we may need something like
> https://github.com/haskell/cabal/issues/948
>  
> --
> Eric Kow 
>  
> --
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> ___
> wxhaskell-devel mailing list
> wxhaskell-devel@lists.sourceforge.net 
> (mailto:wxhaskell-devel@lists.sourceforge.net)
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
>  
>  


--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] Build

[Eric Kow]

On 31 May 2013 06:34, harry  wrote:
> The first problem is that wxdirect installs both executables and a library -
> why is that necessary, and is there another way to do it?

Could you elaborate on this? I'm not 100% sure I follow.

Is the issue something related to the wxdirect executable not being
available in the sandbox environment?

One issue is that wxdirect is used in the build process of the wxcore Setup.hs

One thing which I think might help matters is if we had a way for the
custom Setup.hs in wxcore to depend on wxdirect.  Now one option would
be for us to just swallow wxdirect directly into wxcore, making it
part of the setup script.  There's no particular reason it has to be
run as an executable.

If not feasible, then we may need something like
https://github.com/haskell/cabal/issues/948

--
Eric Kow 

--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] Build

[harry]

Blair Archibald  writes:

> The logical first step seems to be to combine the 3 packages (wxcore, wx,
wxc) into some form of singly installed package. I'm a novice when it comes
to cabal so not sure how what the effects of such a change could be.
> I appreciate that cabal is a great system for installing Haskell packages
but perhaps we should provide additional install methods that also come
pro-bundled with wxWidgets, this way we can control the version that we ship
with - again the issue comes with how to install them on different platforms
and in a controlled manner.

The first problem is that wxdirect installs both executables and a library -
why is that necessary, and is there another way to do it?


--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] Build

[Eric Kow]

Simpler would be fantastic, but there are technical reasons for the current 
setup. If you can meet the same goals whilst delivering an easier install 
experience (or boldly cut off goals that can be better understood as 
wrongheaded), more power to ya!

* wxc - C++ to C wrapper. Uses make (or can be easily persuaded to do so?) to 
enable collaboration with non Haskell projects. I may be wrong here, wasn't 
involved in recent round of simplifications

* wxdirect - generates code from header files? 

* wxcore - C to Haskell. partly auto generated by wxdirect. This is what makes 
it vaguely possible to run the wxWidgets treadmill

* wxc - the easy part. Nice mid level completely static Haskell. Nice to have a 
part people can hack on that without low level concerns 

With this sort if layering in mind, each layer providing some goals, can we do 
anything to improve the situation?



On 30 May 2013, at 21:16, Blair Archibald  wrote:

> I agree that the current deployment system for wxHaskell is not ideal and we 
> should probably look into changing it. Does anyone have any ideas as to how 
> we could go about this?
> 
> The logical first step seems to be to combine the 3 packages (wxcore, wx, 
> wxc) into some form of singly installed package. I'm a novice when it comes 
> to cabal so not sure how what the effects of such a change could be.
> 
> I appreciate that cabal is a great system for installing Haskell packages but 
> perhaps we should provide additional install methods that also come 
> pro-bundled with wxWidgets, this way we can control the version that we ship 
> with - again the issue comes with how to install them on different platforms 
> and in a controlled manner.
> 
> These are just a few ideas. I'd be willing to work on additional deployment 
> methods if anyone wants to take this on and needs help (as I say I'm possibly 
> too novice at wxHaskell and Cabal to get this right on my own). 
> 
> Many thanks,
> Blair
> 
> 
> On 30 May 2013 19:04, harry  wrote:
>> Building Gtk2Hs on Windows is very straightforward. After Gtk+ is included
>> in the path, cabal install gtk2hs-buildtools will install all the
>> executables needed for building the bindings, but no libraries. cabal
>> install gtk will then install the library.
>> 
>> OTOH, cabal install wxdirect installs both the helper executable and a
>> library. 3 other packages then have to be installed, at least one of which
>> requires environment variables pointing to bits of earlier packages. One
>> upshot of all this is that it's well nigh impossible to use wxhaskell with
>> cabal-dev, whereas with gtk2hs it's really easy (install gtk2hs-buildtools
>> outside the sandbox, then gtk will use it in the sandbox).
>> 
>> 
>> --
>> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
>> Get 100% visibility into your production application - at no cost.
>> Code-level diagnostics for performance bottlenecks with <2% overhead
>> Download for free and get started troubleshooting in minutes.
>> http://p.sf.net/sfu/appdyn_d2d_ap1
>> ___
>> wxhaskell-devel mailing list
>> wxhaskell-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
> 
> --
> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
> Get 100% visibility into your production application - at no cost.
> Code-level diagnostics for performance bottlenecks with <2% overhead
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap1
> ___
> wxhaskell-devel mailing list
> wxhaskell-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] Build

[Blair Archibald]

I agree that the current deployment system for wxHaskell is not ideal and
we should probably look into changing it. Does anyone have any ideas as to
how we could go about this?

The logical first step seems to be to combine the 3 packages (wxcore, wx,
wxc) into some form of singly installed package. I'm a novice when it comes
to cabal so not sure how what the effects of such a change could be.

I appreciate that cabal is a great system for installing Haskell packages
but perhaps we should provide additional install methods that also come
pro-bundled with wxWidgets, this way we can control the version that we
ship with - again the issue comes with how to install them on different
platforms and in a controlled manner.

These are just a few ideas. I'd be willing to work on additional deployment
methods if anyone wants to take this on and needs help (as I say I'm
possibly too novice at wxHaskell and Cabal to get this right on my own).

Many thanks,
Blair


On 30 May 2013 19:04, harry  wrote:

> Building Gtk2Hs on Windows is very straightforward. After Gtk+ is included
> in the path, cabal install gtk2hs-buildtools will install all the
> executables needed for building the bindings, but no libraries. cabal
> install gtk will then install the library.
>
> OTOH, cabal install wxdirect installs both the helper executable and a
> library. 3 other packages then have to be installed, at least one of which
> requires environment variables pointing to bits of earlier packages. One
> upshot of all this is that it's well nigh impossible to use wxhaskell with
> cabal-dev, whereas with gtk2hs it's really easy (install gtk2hs-buildtools
> outside the sandbox, then gtk will use it in the sandbox).
>
>
>
> --
> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
> Get 100% visibility into your production application - at no cost.
> Code-level diagnostics for performance bottlenecks with <2% overhead
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap1
> ___
> wxhaskell-devel mailing list
> wxhaskell-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
>
--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

[wxhaskell-devel] Build

[harry]

Building Gtk2Hs on Windows is very straightforward. After Gtk+ is included
in the path, cabal install gtk2hs-buildtools will install all the
executables needed for building the bindings, but no libraries. cabal
install gtk will then install the library.

OTOH, cabal install wxdirect installs both the helper executable and a
library. 3 other packages then have to be installed, at least one of which
requires environment variables pointing to bits of earlier packages. One
upshot of all this is that it's well nigh impossible to use wxhaskell with
cabal-dev, whereas with gtk2hs it's really easy (install gtk2hs-buildtools
outside the sandbox, then gtk will use it in the sandbox).


--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

[wxhaskell-devel] Build errors for wxHaskell

[Edward Amsden]

I have just installed wxHaskell 2.9.3 on OS X Lion from source.

When I run cabal install wx, wxc building fails with the following error:

src/cpp/ewxw_main.cpp: In function ‘void
ELJApp_InitializeC(wxClosure*, int, char**)’:
src/cpp/ewxw_main.cpp:99: warning: deprecated conversion from string
constant to ‘char*’
src/cpp/ewxw_main.cpp:112: error: ‘wxPendingEvents’ was not declared
in this scope
src/cpp/ewxw_main.cpp: In function ‘void ELJApp_initialize(void*, bool
(*)(), int, void*)’:
src/cpp/ewxw_main.cpp:123: error: ‘wxPendingEvents’ was not declared
in this scope

--
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-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] Build error

[Don Stewart]

shelarcy:
> On Fri, 06 Mar 2009 02:45:28 +0900, Don Stewart  wrote:
> > Much better,
> >
> > (snip)
> >
> > cat config/wxcore.pkg | sed -e "s|\${wxhlibdir}|/usr/lib|" | ghc-pkg
> > update -
> > Reading package info from stdin ... done.
> > ghc-pkg: /usr/lib/imports doesn't exist or isn't a directory (use
> > --force to override)
> >
> >
> > Still don't quite get there. Any thoughts?
> 
> You should use following command to install wxHaskell's packages by cabal.
> 
> cabal install wx --configure-opt="--user --enable-split-objs --hcprof" 
> 
> or
> 
> sudo cabal install wx --global
> 
> This is current Cabalization's problem.
> 
> http://haskell.org/haskellwiki/WxHaskell/Troubleshooting#Compilation_issues
> http://hackage.haskell.org/trac/hackage/ticket/431
> 
> 

Oh, I am using the following (as part of making an Arch Linux package):

runhaskell Setup configure --prefix=/usr || return 1
runhaskell Setup build   || return 1
runhaskell Setup register   --gen-script || return 1

Do we know if this should work?

--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] Build error

[shelarcy]

On Fri, 06 Mar 2009 02:45:28 +0900, Don Stewart  wrote:
> Much better,
>
> (snip)
>
> cat config/wxcore.pkg | sed -e "s|\${wxhlibdir}|/usr/lib|" | ghc-pkg
> update -
> Reading package info from stdin ... done.
> ghc-pkg: /usr/lib/imports doesn't exist or isn't a directory (use
> --force to override)
>
>
> Still don't quite get there. Any thoughts?

You should use following command to install wxHaskell's packages by cabal.

cabal install wx --configure-opt="--user --enable-split-objs --hcprof" 

or

sudo cabal install wx --global

This is current Cabalization's problem.

http://haskell.org/haskellwiki/WxHaskell/Troubleshooting#Compilation_issues
http://hackage.haskell.org/trac/hackage/ticket/431


Best Regards,

-- 
shelarcy 
http://page.freett.com/shelarcy/

--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] Build error

[Don Stewart]

shelarcy:
> Hi,
> 
> On Thu, 05 Mar 2009 15:04:23 +0900, Don Stewart  wrote:
> > wxc/src/eljdc.cpp: In function ‘void wxDC_EndDrawing(wxDC*)’:
> > wxc/src/eljdc.cpp:26: warning: ‘void wxDCBase::EndDrawing()’ is deprecated 
> > (declared at /usr/include/wx-2.8/wx/dc.h:393)
> > wxc/src/eljdc.cpp: At global scope:
> > wxc/src/eljdc.cpp:629: error: ‘wxMetafile’ was not declared in this scope
> > wxc/src/eljdc.cpp:629: error: ‘self’ was not declared in this scope
> > wxc/src/eljdc.cpp:629: error: expected primary-expression before ‘int’
> > wxc/src/eljdc.cpp:629: error: expected primary-expression before ‘int’
> > wxc/src/eljdc.cpp:629: error: initializer expression list treated as 
> > compound expression
> > wxc/src/eljdc.cpp:630: error: expected ‘,’ or ‘;’ before ‘{’ token
> > wxc/src/eljdc.cpp:638: error: ‘wxMetafile’ was not declared in this scope
> > wxc/src/eljdc.cpp:638: error: ‘self’ was not declared in this scope
> > wxc/src/eljdc.cpp:638: error: expected primary-expression before ‘*’ token
> > wxc/src/eljdc.cpp:638: error: ‘_dc’ was not declared in this scope
> > wxc/src/eljdc.cpp:638: error: initializer expression list treated as 
> > compound expression
> > wxc/src/eljdc.cpp:639: error: expected ‘,’ or ‘;’ before ‘{’ token
> > wxc/src/eljdc.cpp:647: error: ‘wxMetafile’ was not declared in this scope
> > wxc/src/eljdc.cpp:647: error: ‘self’ was not declared in this scope
> > wxc/src/eljdc.cpp:648: error: expected ‘,’ or ‘;’ before ‘{’ token
> > wxc/src/eljdc.cpp:656: error: variable or field ‘wxMetafile_Delete’ 
> > declared void
> > wxc/src/eljdc.cpp:656: error: ‘wxMetafile’ was not declared in this scope
> > wxc/src/eljdc.cpp:656: error: ‘self’ was not declared in this scope
> 
> I fixed this bug in the new HackageDB releace 0.11.1.2.
> Please test again with 0.11.1.2.
> 
> And I'll send darcs patch for this problem later.

Much better,

ld -r -o dist/wxcore/wxcore.o
dist/wxcore/imports/Graphics/UI/WXCore/WxcClasses.o
dist/wxcore/imports/Graphics/UI/WXCore/WxcClassInfo.o
dist/wxcore/imports/Graphics/UI/WXCore/WxcDefs.o
dist/wxcore/imports/Graphics/UI/WXCore/Types.o
dist/wxcore/imports/Graphics/UI/WXCore/Defines.o
dist/wxcore/imports/Graphics/UI/WXCore/Draw.o
dist/wxcore/imports/Graphics/UI/WXCore/Image.o
dist/wxcore/imports/Graphics/UI/WXCore/Events.o
dist/wxcore/imports/Graphics/UI/WXCore/DragAndDrop.o
dist/wxcore/imports/Graphics/UI/WXCore/Frame.o
dist/wxcore/imports/Graphics/UI/WXCore/Layout.o
dist/wxcore/imports/Graphics/UI/WXCore/Process.o
dist/wxcore/imports/Graphics/UI/WXCore/Print.o
dist/wxcore/imports/Graphics/UI/WXCore/Dialogs.o
dist/wxcore/imports/Graphics/UI/WXCore/Controls.o
dist/wxcore/imports/Graphics/UI/WXCore/Db.o
dist/wxcore/imports/Graphics/UI/WXCore/OpenGL.o
dist/wxcore/imports/Graphics/UI/WXCore.o
dist/wxcore/imports/Graphics/UI/WXCore/Events_stub.o
cat config/wxcore.pkg | sed -e "s|\${wxhlibdir}|/usr/lib|" | ghc-pkg
update -
Reading package info from stdin ... done.
ghc-pkg: /usr/lib/imports doesn't exist or isn't a directory (use
--force to override)


Still don't quite get there. Any thoughts?

--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] Build error

[shelarcy]

Hi,

On Thu, 05 Mar 2009 15:04:23 +0900, Don Stewart  wrote:
> wxc/src/eljdc.cpp: In function ‘void wxDC_EndDrawing(wxDC*)’:
> wxc/src/eljdc.cpp:26: warning: ‘void wxDCBase::EndDrawing()’ is deprecated 
> (declared at /usr/include/wx-2.8/wx/dc.h:393)
> wxc/src/eljdc.cpp: At global scope:
> wxc/src/eljdc.cpp:629: error: ‘wxMetafile’ was not declared in this scope
> wxc/src/eljdc.cpp:629: error: ‘self’ was not declared in this scope
> wxc/src/eljdc.cpp:629: error: expected primary-expression before ‘int’
> wxc/src/eljdc.cpp:629: error: expected primary-expression before ‘int’
> wxc/src/eljdc.cpp:629: error: initializer expression list treated as compound 
> expression
> wxc/src/eljdc.cpp:630: error: expected ‘,’ or ‘;’ before ‘{’ token
> wxc/src/eljdc.cpp:638: error: ‘wxMetafile’ was not declared in this scope
> wxc/src/eljdc.cpp:638: error: ‘self’ was not declared in this scope
> wxc/src/eljdc.cpp:638: error: expected primary-expression before ‘*’ token
> wxc/src/eljdc.cpp:638: error: ‘_dc’ was not declared in this scope
> wxc/src/eljdc.cpp:638: error: initializer expression list treated as compound 
> expression
> wxc/src/eljdc.cpp:639: error: expected ‘,’ or ‘;’ before ‘{’ token
> wxc/src/eljdc.cpp:647: error: ‘wxMetafile’ was not declared in this scope
> wxc/src/eljdc.cpp:647: error: ‘self’ was not declared in this scope
> wxc/src/eljdc.cpp:648: error: expected ‘,’ or ‘;’ before ‘{’ token
> wxc/src/eljdc.cpp:656: error: variable or field ‘wxMetafile_Delete’ declared 
> void
> wxc/src/eljdc.cpp:656: error: ‘wxMetafile’ was not declared in this scope
> wxc/src/eljdc.cpp:656: error: ‘self’ was not declared in this scope

I fixed this bug in the new HackageDB releace 0.11.1.2.
Please test again with 0.11.1.2.

And I'll send darcs patch for this problem later.


Best Regards,

-- 
shelarcy 
http://page.freett.com/shelarcy/

--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

[wxhaskell-devel] Build error

[Don Stewart]

wxc/src/eljdc.cpp: In function ‘void wxDC_EndDrawing(wxDC*)’:
wxc/src/eljdc.cpp:26: warning: ‘void wxDCBase::EndDrawing()’ is deprecated 
(declared at /usr/include/wx-2.8/wx/dc.h:393)
wxc/src/eljdc.cpp: At global scope:
wxc/src/eljdc.cpp:629: error: ‘wxMetafile’ was not declared in this scope
wxc/src/eljdc.cpp:629: error: ‘self’ was not declared in this scope
wxc/src/eljdc.cpp:629: error: expected primary-expression before ‘int’
wxc/src/eljdc.cpp:629: error: expected primary-expression before ‘int’
wxc/src/eljdc.cpp:629: error: initializer expression list treated as compound 
expression
wxc/src/eljdc.cpp:630: error: expected ‘,’ or ‘;’ before ‘{’ token
wxc/src/eljdc.cpp:638: error: ‘wxMetafile’ was not declared in this scope
wxc/src/eljdc.cpp:638: error: ‘self’ was not declared in this scope
wxc/src/eljdc.cpp:638: error: expected primary-expression before ‘*’ token
wxc/src/eljdc.cpp:638: error: ‘_dc’ was not declared in this scope
wxc/src/eljdc.cpp:638: error: initializer expression list treated as compound 
expression
wxc/src/eljdc.cpp:639: error: expected ‘,’ or ‘;’ before ‘{’ token
wxc/src/eljdc.cpp:647: error: ‘wxMetafile’ was not declared in this scope
wxc/src/eljdc.cpp:647: error: ‘self’ was not declared in this scope
wxc/src/eljdc.cpp:648: error: expected ‘,’ or ‘;’ before ‘{’ token
wxc/src/eljdc.cpp:656: error: variable or field ‘wxMetafile_Delete’ declared 
void
wxc/src/eljdc.cpp:656: error: ‘wxMetafile’ was not declared in this scope
wxc/src/eljdc.cpp:656: error: ‘self’ was not declared in this scope


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] build failure in new release

[Don Stewart]

shelarcy:
> Hi,
> 
> On Sat, 11 Oct 2008 11:26:43 +0900, Don Stewart <[EMAIL PROTECTED]> wrote:
> > configuration:
> >  library: wxhaskell-0.10.4  (release 0)
> >  (snip)
> >
> > *** config/config.mk:22: *** missing separator.  Stop.
> > cabal: Error: some packages failed to install:
> > wxcore-0.10.4 failed during the building phase. The exception was:
> > exit: ExitFailure 2
> >
> > Typo in config.mk
> >
> > # Packages
> > PKG-CONTAINERS=-package containers-0.2.0.0
> > PKG-PARSEC=-package parsec-2.1.0.1
> > 2.1.0.2
> > PKG-TIME=-package time-1.1.2.1
> > PKG-STM=-package stm-2.1.1.1
> 
> I fixed this bug in the new HackageDB releace 0.10.5.
> Please test again with 0.10.5.
> 
> And I sent darcs patch for this bug (and 2 more).
> I will push tomorrow unless somebody complains that.
> 
> http://sourceforge.net/mailarchive/forum.php?thread_name=FF3769EA396C4DA4B1FC7BF317CFF6A8%40ShelarcyWin&forum_name=wxhaskell-devel
> 
> 

Thanks, fixes that.

I still get this error on Arch Linux,

ld -r -o dist/wxcore/wxcore.o 
dist/wxcore/imports/Graphics/UI/WXCore/WxcClasses.o 
dist/wxcore/imports/Graphics/UI/WXCore/WxcClassInfo.o 
dist/wxcore/imports/Graphics/UI/WXCore/WxcDefs.o 
dist/wxcore/imports/Graphics/UI/WXCore/Types.o 
dist/wxcore/imports/Graphics/UI/WXCore/Defines.o 
dist/wxcore/imports/Graphics/UI/WXCore/Draw.o 
dist/wxcore/imports/Graphics/UI/WXCore/Image.o 
dist/wxcore/imports/Graphics/UI/WXCore/Events.o 
dist/wxcore/imports/Graphics/UI/WXCore/DragAndDrop.o 
dist/wxcore/imports/Graphics/UI/WXCore/Frame.o 
dist/wxcore/imports/Graphics/UI/WXCore/Layout.o 
dist/wxcore/imports/Graphics/UI/WXCore/Process.o 
dist/wxcore/imports/Graphics/UI/WXCore/Print.o 
dist/wxcore/imports/Graphics/UI/WXCore/Dialogs.o 
dist/wxcore/imports/Graphics/UI/WXCore/Controls.o 
dist/wxcore/imports/Graphics/UI/WXCore/Db.o 
dist/wxcore/imports/Graphics/UI/WXCore/OpenGL.o 
dist/wxcore/imports/Graphics/UI/WXCore.o 
dist/wxcore/imports/Graphics/UI/WXCore/Events_stub.o
cat config/wxcore.pkg | sed -e "s|\${wxhlibdir}|/usr/lib|" | ghc-pkg update -
Reading package info from stdin ... done.
ghc-pkg: /usr/lib/imports doesn't exist or isn't a directory (use --force to 
override)

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] build failure in new release

[Don Stewart]

shelarcy:
> Hi,
> 
> On Sat, 11 Oct 2008 11:26:43 +0900, Don Stewart <[EMAIL PROTECTED]> wrote:
> > configuration:
> >  library: wxhaskell-0.10.4  (release 0)
> >  (snip)
> >
> > *** config/config.mk:22: *** missing separator.  Stop.
> > cabal: Error: some packages failed to install:
> > wxcore-0.10.4 failed during the building phase. The exception was:
> > exit: ExitFailure 2
> >
> > Typo in config.mk
> >
> > # Packages
> > PKG-CONTAINERS=-package containers-0.2.0.0
> > PKG-PARSEC=-package parsec-2.1.0.1
> > 2.1.0.2
> > PKG-TIME=-package time-1.1.2.1
> > PKG-STM=-package stm-2.1.1.1
> 
> I fixed this bug in the new HackageDB releace 0.10.5.
> Please test again with 0.10.5.
> 
> And I sent darcs patch for this bug (and 2 more).
> I will push tomorrow unless somebody complains that.
> 
> http://sourceforge.net/mailarchive/forum.php?thread_name=FF3769EA396C4DA4B1FC7BF317CFF6A8%40ShelarcyWin&forum_name=wxhaskell-devel
> 
> 
> Best Regards,

And I got wx and wxcore to build *out of the box* with cabal install
0.6, cabal 1.6 and ghc 6.10!!!

Yay!

-- Don

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] build failure in new release

[shelarcy]

Hi,

On Sat, 11 Oct 2008 11:26:43 +0900, Don Stewart <[EMAIL PROTECTED]> wrote:
> configuration:
>  library: wxhaskell-0.10.4  (release 0)
>  (snip)
>
> *** config/config.mk:22: *** missing separator.  Stop.
> cabal: Error: some packages failed to install:
> wxcore-0.10.4 failed during the building phase. The exception was:
> exit: ExitFailure 2
>
> Typo in config.mk
>
> # Packages
> PKG-CONTAINERS=-package containers-0.2.0.0
> PKG-PARSEC=-package parsec-2.1.0.1
> 2.1.0.2
> PKG-TIME=-package time-1.1.2.1
> PKG-STM=-package stm-2.1.1.1

I fixed this bug in the new HackageDB releace 0.10.5.
Please test again with 0.10.5.

And I sent darcs patch for this bug (and 2 more).
I will push tomorrow unless somebody complains that.

http://sourceforge.net/mailarchive/forum.php?thread_name=FF3769EA396C4DA4B1FC7BF317CFF6A8%40ShelarcyWin&forum_name=wxhaskell-devel


Best Regards,

-- 
shelarcy 
http://page.freett.com/shelarcy/

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

[wxhaskell-devel] build failure in new release

[Don Stewart]

configuration:
 library: wxhaskell-0.10.4  (release 0)
 compiler:ghc-6.10.0.20081007
 wxwidgets:   gtk-2.8.9
 extensions:
   openGL:no
   mediactrl: no
   contrib:   no
 library dir: /home/dons/.cabal/lib

done:
 type 'make' to build wxhaskell.
 type 'make install' to install wxhaskell.
 type 'make help' to receive help on all other make targets

*** config/config.mk:22: *** missing separator.  Stop.
cabal: Error: some packages failed to install:
wxcore-0.10.4 failed during the building phase. The exception was:
exit: ExitFailure 2


Typo in config.mk

# Packages 
PKG-CONTAINERS=-package containers-0.2.0.0 
PKG-PARSEC=-package parsec-2.1.0.1 
2.1.0.2 
PKG-TIME=-package time-1.1.2.1 
PKG-STM=-package stm-2.1.1.1

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel