I'm trying to set up a build environment for wxHaskell using Nix and Stack.
I've installed wxWidgets-3.0.2 through nix. This is the relevant portion from by .cabal file
executable hellowx-exe
hs-source-dirs: app
main-is: Main.hs
ghc-options: -threaded -rtsopts -with-rtsopts=-N
build-depends: base
, hellowx
, wx
, wxc
, wxcore
, wxdirect
and the stack.yaml file
resolver: lts-5.0
extra-deps:
- wx-0.92.2.0
- wxc-0.92.2.0
- wxcore-0.92.2.0
- wxdirect-0.92.2.0
I tried adding
nix:
enable: true
packages: [wxwidgets]
but that wasn't the right way apparently.
So I got rid of the nix part in the .yaml file and tried the command $ stack --nix build which resulted in failure. The log file said
[1 of 1] Compiling Main ( /run/user/1000/stack8847/wxc-0.92.2.0/Setup.hs, /run/user/1000/stack8847/wxc-0.92.2.0/.stack-work/dist/x86_64-linux-nix/Cabal-1.22.5.0/setup/Main.o )
Linking /run/user/1000/stack8847/wxc-0.92.2.0/.stack-work/dist/x86_64-linux-nix/Cabal-1.22.5.0/setup/setup ...
Error: wx-config not found, please install wx-config before installing wxc
However I do have wx-config and wxwidgets installed through nix. The build process can't find it for some reason. What can I do to set up this build environment? Is there a way to direct the build process to look in the directory containing wx-config? I can't figure out why it can't find it. Its in the PATH.
Ok, I figured it out. I was adding the wrong "attribute name". Here is the correct stack.yaml file
# at this point in time nix supports lts-5.0
resolver: lts-5.0
packages:
-'.'
extra-deps:
- wx-0.92.2.0
- wxc-0.92.2.0
- wxcore-0.92.2.0
- wxdirect-0.92.2.0
# wxwidgets-3.0.2 has the attribute name wxGTK30
# you also need zlib, mesa_noglu and x11
nix:
enable: true
packages: [zlib, wxGTK30, mesa_noglu, x11]
That seems to build everything properly, and I was able to build a minimal window from here (minimal.hs)
Related
I want to build the haskell bindings for z3 in a Cabal project, the following is the minimum (faulty) example:
Using a project initialized by cabal init:
test/
- Main.hs
- Setup.hs
- CHANGELOG.md
- test.cabal
With modified test.cabal:
cabal-version: 3.0
name: z3-test
version: 0.1.0.0
extra-source-files: CHANGELOG.md
executable test
main-is: Main.hs
build-depends: base >=4.14 && <4.15
, z3 ^>=408.2
default-language: Haskell2010
Z3 binaries are located at C:\z3-4.8.5-x86-win.
Z3-bindings are installed:
cabal v1-install z3 --extra-lib-dirs=C:/z3-4.8.5-x64-win/bin --extra-include-dirs=C:/z3-4.8.5-x64-win/include -v3
All the requested packages are already installed:
z3-408.2
Use --reinstall if you want to reinstall anyway.
Now building the project using:
cabal v2-build --extra-lib-dirs=C:/z3-4.8.5-x64-win/bin --extra-include-dirs=C:/z3-4.8.5-x64-win/include -v3
Results in the error:
Build profile: -w ghc-8.10.2 -O1
In order, the following will be built (use -v for more details):
- z3-408.2 (lib) (requires build)
- z3-test-0.1.0.0 (exe:test) (first run)
Starting z3-408.2 (lib)
Failed to build z3-408.2. The failure occurred during the configure step.
Build log (
C:\cabal\logs\ghc-8.10.2\z3-408.2-1722a25655334afbca91ac935f14ff0d20ccf8c4.log
):
Configuring library for z3-408.2..
cabal.exe: Missing dependency on a foreign library:
* Missing (or bad) header file: z3.h
* Missing (or bad) C library: z3
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.If the
library file does exist, it may contain errors that are caught by the C
compiler at the preprocessing stage. In this case you can re-run configure
with the verbosity flag -v3 to see the error messages.
If the header file does exist, it may contain errors that are caught by the C
compiler at the preprocessing stage. In this case you can re-run configure
with the verbosity flag -v3 to see the error messages.
cabal.exe: Failed to build z3-408.2 (which is required by exe:test from
z3-test-0.1.0.0). See the build log above for details.
How can I build a project with the z3 bindings?
Note that:
GHC version = 8.10.2
Cabal version = 3.2.0.0
I can only use cabal
Using cabal install ... or cabal v2-install ... results in Cannot build .. z3 because none of the components are available to build:
I have projects compiling with cabal build (but using hpack for the convenience). For some reason, I would like to compile them with stack build. What goes into a minimal stack.yaml file?
The stack documentation gives details what goes into such a file, but does not show a minimal (or any, as much as I can see) example. I fear to use stack init on an existing project for unintended consequences.
What is a small example from which to go?
A minimal stack.yaml:
resolver: lts-19.16 # for ghc 9.0.2 newest lts
packages:
- .
A not-so minimal skeleton from which to expand:
resolver: lts-19.16 # for ghc 9.0.2 newest lts
packages:
- .
extra-deps: # include here other local packages
ghc-options:
"$everything": -haddock # to produce documentation with haddock
I have a stack project using Sound.ALUT. The project was building fine on both Windows and Mac before I added sound. (Sound.ALUT is a library layered over OpenAL.) Got thinks working on MacOS but those changes broke the Windows build. Still builds fine on MacOS.
The offending snippit from the "stack build" console log on Windows looks like this
GLUT > [22 of 24] Compiling Graphics.UI.GLUT.Callbacks.Global
GLUT > [23 of 24] Compiling Graphics.UI.GLUT.Callbacks
GLUT > [24 of 24] Compiling Graphics.UI.GLUT
GLUT > copy/register
GLUT > Installing library in C:\sr\snapshots\87ecdd59\lib\x86_64-windows-ghc-8.10.7\GLUT-2.7.0.16-2jeyeunHWey2D1Huuhst8j
GLUT > Registering library for GLUT-2.7.0.16..
OpenAL > configure
OpenAL > Configuring OpenAL-1.7.0.5...
OpenAL > Cabal-simple_Z6RU0evB_3.2.1.0_ghc-8.10.7.exe: Missing dependency on a foreign
OpenAL > library:
OpenAL > * Missing (or bad) C library: OpenAL32
OpenAL > This problem can usually be solved by installing the system package that
OpenAL > provides this library (you may need the "-dev" version). If the library is
OpenAL > already installed but in a non-standard location then you can use the flags
OpenAL > --extra-include-dirs= and --extra-lib-dirs= to specify where it is.If the
OpenAL > library file does exist, it may contain errors that are caught by the C
OpenAL > compiler at the preprocessing stage. In this case you can re-run configure
OpenAL > with the verbosity flag -v3 to see the error messages.
OpenAL >
Progress 10/21
Cleary it can't find OpenAL. I've tried:
installing OpenAL using the Windows installer from https://www.openal.org/downloads
cloning and building openal-soft https://github.com/kcat/openal-soft on windows
setting the --extra-include-dirs and --extra-lib-dirs inslide my stack.yaml to point to where the libraries should be.
I had similar issues getting Sound.ALUT working on the Mac build. In that case building from the sources seemed to solve the problems. I have more trouble building on Windows since the build environment is less familiar. My Windows work has mostly been centered around installing Cygwin and making it look like Unix. But this time, I'm trying to get by on what stack's mingw-w64 provides. I was pulling down things with stack exec -- pacman trying to find something that would install OpenAL as a side effect but no luck.
Some subtleties arise from the fact that stack want to install things in its own self-contained environment. It tries to keep installs localized inside the project directory and not muck around with directories elsewhere. My stack environment looks like this
C:\Users\Mark\slgjff>stack path
snapshot-doc-root: C:\sr\snapshots\aff7b821\doc
local-doc-root: C:\Users\Mark\slgjff\.stack-work\install\f5431f41\doc
local-hoogle-root: C:\Users\Mark\slgjff\.stack-work\hoogle\f5431f41
stack-root: C:\sr
project-root: C:\Users\Mark\slgjff
config-location: C:\Users\Mark\slgjff\stack.yaml
bin-path: .;C:\sr\snapshots\87ecdd59\bin;C:\sr\compiler-tools\x86_64-windows\ghc-8.10.7\bin;C:\Users\Mark\AppData\Local\Programs\stack\x86_64-windows\ghc-8.10.7\bin;C:\Users\Mark\AppData\Local\Programs\stack\x86_64-windows\ghc-8.10.7\mingw\bin;C:\Users\Mark\AppData\Local\Programs\stack\x86_64-windows\msys2-20220503\mingw64\bin;C:\Users\Mark\AppData\Local\Programs\stack\x86_64-windows\msys2-20220503\usr\bin;C:\Users\Mark\AppData\Local\Programs\stack\x86_64-windows\msys2-20220503\usr\local\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\Git\cmd;C:\Users\Mark\AppData\Roaming\local\bin;C:\Users\Mark\AppData\Local\Microsoft\WindowsApps
programs: C:\Users\Mark\AppData\Local\Programs\stack\x86_64-windows
compiler-exe: C:\Users\Mark\AppData\Local\Programs\stack\x86_64-windows\ghc-8.10.7\bin\ghc-8.10.7.exe
compiler-bin: C:\Users\Mark\AppData\Local\Programs\stack\x86_64-windows\ghc-8.10.7\bin
compiler-tools-bin: C:\sr\compiler-tools\x86_64-windows\ghc-8.10.7\bin
local-bin: C:\Users\Mark\AppData\Roaming\local\bin
extra-include-dirs: C:\Users\Mark\AppData\Local\Programs\stack\x86_64-windows\msys2-20220503\mingw64\include
extra-library-dirs: C:\Users\Mark\AppData\Local\Programs\stack\x86_64-windows\msys2-20220503\mingw64\lib, C:\Users\Mark\AppData\Local\Programs\stack\x86_64-windows\msys2-20220503\mingw64\bin
snapshot-pkg-db: C:\sr\snapshots\87ecdd59\pkgdb
local-pkg-db: C:\Users\Mark\slgjff\.stack-work\install\363b2fd8\pkgdb
global-pkg-db: C:\Users\Mark\AppData\Local\Programs\stack\x86_64-windows\ghc-8.10.7\lib\package.conf.d
ghc-package-path: C:\Users\Mark\slgjff\.stack-work\install\363b2fd8\pkgdb;C:\sr\snapshots\87ecdd59\pkgdb;C:\Users\Mark\AppData\Local\Programs\stack\x86_64-windows\ghc-8.10.7\lib\package.conf.d
snapshot-install-root: C:\sr\snapshots\87ecdd59
local-install-root: C:\Users\Mark\slgjff\.stack-work\install\363b2fd8
dist-dir: .stack-work\dist\274b403a
local-hpc-root: C:\Users\Mark\slgjff\.stack-work\install\363b2fd8\hpc
local-bin-path: C:\Users\Mark\AppData\Roaming\local\bin
ghc-paths: C:\Users\Mark\AppData\Local\Programs\stack\x86_64-windows
I'm not sure the configure needs to be happy. I wish I could construct a checklist run through, but I don't understand enough to write that checklist. Do it need the C source for header files? Don't know. Certainly it must need the .lib and .dlls on the path somewhere. But which path exactly?
My package.yaml -- which works fine on MacOS
ghc-options:
#- -dynamic
- -static
dependencies:
- base >= 4.7 && < 5
- random
- gloss
- gloss-juicy
- ALUT
library:
source-dirs: src
executables:
slgjff-exe:
main: Main.hs
source-dirs: app
ghc-options:
- -threaded
- -rtsopts
- -with-rtsopts=-N
dependencies:
- slgjff
tests:
slgjff-test:
main: Spec.hs
source-dirs: test
ghc-options:
- -threaded
- -rtsopts
- -with-rtsopts=-N
dependencies:
- slgjff
And my stack.yaml -- which also works fine on MacOS
resolver:
url: https://raw.githubusercontent.com/commercialhaskell/stackage-snapshots/master/lts/18/24.yaml
packages:
- .
extra-deps:
- gloss-1.13.2.1#sha256:273d02d30e1896932d45424dab6022a16986c0ed3eef6937776b5f40854ce51c,4075
- JuicyPixels-3.3.6#sha256:03bd32c3a884ac8a32f49334f14695469a710945c84cef9a1e059a79ac416996,3911
- gloss-juicy-0.2.3
And because it may be helpful, here are the includes at top of my program.
import System.Exit ( exitSuccess, exitFailure )
import System.IO ( hPutStrLn, stderr )
import Data.List
import Graphics.Gloss
import Graphics.Gloss.Interface.Pure.Game
import Graphics.Gloss.Interface.IO.Game
import Graphics.Gloss.Data.Vector
import Graphics.Gloss.Juicy
import Control.Monad( when, unless )
import Sound.ALUT as S
I got so desperate I stuck C:/Windows/System32 on the path and almost spilled my drink when the build tried to delete files from C:/Windows/System32. So, I took that out. Running out of ideas.
My sense is that out of inexperience with ghc on Windows, I must be missing something that would be really obvious to someone with more experience. Thanks in advance for any insights.
P.S. I created a stripped down version of the project and put it up on github at https://github.com/markcornwell/alut-glitch
See the README for the project for instruction on how to reproduce the error.
I'm using inline-c and I have two C files that I'd like to call in the Haskell code. In the Cabal file, there are:
include-dirs: cbits
, /usr/local/include
c-sources: cbits/genann.c
In the Cbits directory, there's also genann.h
I can build and run the project without problem but when I do cabal install, the compiler complain that it can't find the C header file.
I checked the Cabal manual and added the following options:
includes: cbits/genann.h
install-includes: cbits/genann.h
This time I got:
Configuring executable 'inline-gsl' for inline-gsl-0.1.0.0..
cabal-3.6.2.0: Missing dependency on a foreign library:
* Missing (or bad) header file: cbits/genann.h
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
Where is wrong here? Do I need to compile the C code into object code and put them in the system?
The complete Cabal file:
cabal-version: 2.4
name: inline-gsl
version: 0.1.0.0
-- A short (one-line) description of the package.
-- synopsis:
extra-source-files: CHANGELOG.md
executable inline-gsl
main-is: Main.hs
build-depends: base ^>=4.14.3.0
, inline-c
, vector
, massiv
, array
, bytestring >= 0.10
, template-haskell
hs-source-dirs: app
pkgconfig-depends: glib-2.0, gtk4, gsl
default-language: Haskell2010
extra-libraries: m, tensorflow
extra-lib-dirs: /usr/local/lib
cc-options: -Wall -m64 -O4
include-dirs: cbits
, /usr/local/include
includes: cbits/genann.h
install-includes: cbits/genann.h
c-sources: cbits/genann.c
I can build and run the project without problem but when I do cabal install, the compiler complain that it can't find the C header file.
I believe this indicates that the problem is that your header files are not included in your package source tarballs (sdist). You need to list all non-Haskell source files under the extra-source-files field in your cabal file:
extra-source-files: CHANGELOG.md, cbits/genann.h, cbits/genann.c
I am attempting to build a project which uses Euterpea.
Running stack build I get the following error, suggesting that I need to add Euterpea to the build-depends section of my .cabal file.
$ sb
composition-0.1.0.0: build (lib + exe)
Preprocessing library composition-0.1.0.0...
[2 of 2] Compiling Lib ( src/Lib.hs, .stack-work/dist/x86_64-linux-nix/Cabal-1.24.2.0/build/Lib.o )
/home/matthew/backup/composition/composition/src/Lib.hs:5:1: error:
Failed to load interface for ‘Euterpea’
It is a member of the hidden package ‘Euterpea-2.0.4’.
Perhaps you need to add ‘Euterpea’ to the build-depends in your .cabal file.
Use -v to see a list of the files searched for.
-- While building package composition-0.1.0.0 using:
/home/matthew/.stack/setup-exe-cache/x86_64-linux-nix/Cabal-simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2 --builddir=.stack-work/dist/x86_64-linux-nix/Cabal-1.24.2.0 build lib:composition exe:composition-exe --ghc-options " -ddump-hi -ddump-to-file"
Process exited with code: ExitFailure 1
I add Euterpea there, and the library section of my .cabal file then is the following.
library
hs-source-dirs:
src
build-depends: base >= 4.7 && < 5
, Euterpea
exposed-modules:
Lib
other-modules:
Paths_composition
default-language: Haskell2010
However, when I then run stack build again, it gives the same error -- and changes my .cabal file back to what it was originally, with the library section then looking like
library
hs-source-dirs:
src
build-depends:
base >= 4.7 && < 5
exposed-modules:
Lib
other-modules:
Paths_composition
default-language: Haskell2010
Why is stack build altering my cabal file? I have never seen that occurring before.
Side note:
Not sure if it is related, but the .cabal file's format appears to be different than it normally does. Here as with previous projects I auto-initialized by running stack new <project-name>. I don't know what I might have done different from previous projects to cause this unexpected behavior of stack build.
Make sure package.yaml exists in the root of your project directory.
package.yaml is a new file format to improve the syntax of cabal, converted by hpack.
Stack supports hpack as strongly as the stack build command automatically converts package.yaml into a cabal file with hpack command.
So, delete package.yaml or edit package.yaml to add Euterpea package.
Editing it would not be so difficult as its format is YAML.
I want to add to the YAMAMOTO Yuji's answer. The solution is absolutely right. But I just wanted to add few things, it is not hard to edit the package.yaml.
Step 1 : The trickiest part is finding the correct package name.
Use Hoogle or Stackage to find the package where the module
resides. Read more about how to find package name in this post.
Step 2 : Now you have to open the package.yaml file and add the package name. In your case add 'Euterpea' package in the list of dependencies.
dependencies:
...
- your-package-name
Please note that Euterpea package has to be added in a different way. Please read this
post for better understanding.
Step 3 : Open project-name.cabal in project root and add required package name under build-depends:
library
hs-source-dirs:
src
build-depends:
base >= 4.7 && < 5
, your-package-name
exposed-modules:
Lib
Step 4 :Issue stack build to download and build dependencies
(or stack ghci if you plan to use it in the REPL)
Hope this works! Happy coding! :)