Problem: I've got a command-line tool written in Haskell that reads a data file. Upon installing the program, I'd like for the program to be able to read that data file regardless of the directory I find myself in. That is, upon installing, the path that the program knows should be aligned with the path that the installer chooses.
Initial attempt: I was directed to the section 7.6. Accessing data files from package code in Cabal (the library) and learned that I can import getDataDir :: IO FilePath from Paths_myprog, as long as I add Paths_myprog to other-modules (although Hpack auto-includes this by default) and that after installing my program, I can run it with:
myprog_datadir=~/tmp ~/.local/bin/myprog
Then all I need to do is have the installer move the data file to this directory, since myprog dynamically accesses that path rather than some hardcoded value. But I don't want to have to specify myprog_datadir=~/tmp in my environment every time I run the program, I want it hardcoded into the binary! And it seems that setting myprog_datadir=~/tmp when building and installing doesn't set a compile-time default.
So: Is there a way I can hardcode this path upon installation?
(Preferrably, an answer that relates to Stack, but a cabal-install answer is also greatly appreciated.)
Files listed in data-files are already automatically installed in the right location so that Paths_pkg will find them. Here's a minimal example:
% cat Main.hs
import Paths_so_test
main :: IO ()
main = getDataDir >>= putStrLn
% cat so-test.cabal
cabal-version: >=1.10
name: so-test
version: 0.1.0.0
build-type: Simple
data-files: test
executable so-test
main-is: Main.hs
other-modules: Paths_so_test
autogen-modules: Paths_so_test
build-depends: base >=4.14 && <4.15
default-language: Haskell2010
% cat test
Hello, world!
% cabal install
Wrote tarball sdist to
/home/dmwit/projects/oneoff/tmp.dir/dist-newstyle/sdist/so-test-0.1.0.0.tar.gz
Resolving dependencies...
Up to date
Symlinking 'so-test'
% cat `so-test`/test
Hello, world!
Related
Using cabal repl seems to do nothing at all when used on library projects, but works fine for executable projects. Is this expected behavior that I just don't understand?
If I have a file containing simply
go = putStrLn "test"
and use cabal init with all the defaults (but choose "library" as the type), then running cabal repl just produces the some text about configuring and preprocessing the library and never enters a REPL environment. The exact same steps, but with "executable" selected as the type, puts me right into GHCi as expected.
The code works fine when loaded directly into GHCi.
For cabal repl to load your modules, you have to first name them in code and then specify them in your project's .cabal file as exposed:
-- MyModule.hs
module MyModule where
go = putStrLn "test"
-- MyProject.cabal
name: MyProject
-- other info ...
library
exposed-modules: MyModule
-- other options ...
Then when you run cabal repl, it'll have access to everything in your sandbox (if present) and the exposed modules. It might also work if you specify them as other-modules instead of exposed-modules, but I haven't tried that one out.
I'm messing around with the plugins package however I bumped into a problem.
Here's the code:
Util/Header.hs
module Util.Header(PT(..)) where
data PT a = PT a deriving Show
Plug.hs
module Plug(helloPlugin) where
import Util.Header
helloPlugin :: PT Int
helloPlugin = PT 1
Main.hs
module Main where
import Util.Header
import System.Plugins
main :: IO ()
main = do
mv <- load "Plug.o" ["."] [] "helloPlugin"
case mv of
LoadFailure msg -> print msg
LoadSuccess _ v -> print $ show (v :: PT Int)
This all works fine then compiling with ghc. Building with Cabal works fine as well, but when I run the executable I get this error:
plugintest: /home/kevin/.cabal/lib/plugins-1.5.4.0/ghc-7.6.3/HSplugins-1.5.4.0.o: unknown symbol `ghczm7zi6zi3_ErrUtils_zdsinsertzuzdsgo5_info'
plugintest: user error (resolvedObjs failed.)
My very minimalistic cabal file:
name: plugintest
version: 0.1.0.0
license-file: LICENSE
build-type: Simple
cabal-version: >=1.8
library
hs-source-dirs: src
exposed-modules: Util.Header
build-depends: base ==4.6.*, plugins ==1.5.*
executable plugintest
main-is: Main.hs
build-depends: base ==4.6.*, plugins ==1.5.*, plugintest == 0.1.0.0
hs-source-dirs: src
Now I assume the problem is that it can't find the "ErrUtils" module which is part of the ghc package installed in /usr/lib/ghc-7.x.x.
Since it's using cabal it'll use the $HOME/.cabal/lib/ instead.
Now I obviously wouldn't want to use /usr/lib if I wanted to make it distributable. Sadly I'm not very familiar with how packages are managed nor am I familiar with the plugins package.
I have a feeling this is extremly nooby but I wasn't able to find a solution myself.
So a few questions:
How can I get my dependencies to work in a way to make this distributable?
It seems I'll need to know beforehand what my Plugin.o files will depend on before actually being able to use them (If I understand correctly).
Is there a way to package a .o files that I wouldn't have to worry about this problem? (Sorry if this question is too vague, feel free to ignore)
Thanks in advance!
Ok, so I had the exact same problem.
Here is a workaround I found
Change the load call to
load "Plug.o" [".","dist/build/plugintest/plugintest-tmp"] [] "testplugin"
Make sure you compile the thing with -c or by using the "make" library from plugins.
Quite annoyed by this... The error suggests it is having issues linking against the standard libs, so why does showing it these .o files fix it?
Anyways, this worked for me, and didn't require a ton of mucking around with .cabal files.
You must declare your exported- and other- modules in order for Cabal to package them all together. For instance (from https://github.com/tel/happstack-heroku-test)
name: hktest -- note the name here names
-- the *library* which is a package name
-- in scope when building the executable
...
library
exposed-modules:
HKTest
other-modules:
-- there aren't any, but there could be some
build-depends: base >= 4.6 && <4.7
...
, mtl >= 2.1.2
hs-source-dirs: src
executable server
main-is: Server.hs
other-modules:
-- there might be some use to having these here,
-- but they'll be harder to get into GHCi, so I wouldn't
-- recommend it---just put them in the library part
build-depends: base >=4.6 && <4.7
, hktest -- note that I grab all the hktest
-- modules here
hs-source-dirs: exe
If I leave out one of those modules I'll likely get a build error as Cabal compiles files which expect to be able to find symbols that haven't been packaged.
In your case, since you're building an executable, the common pattern exemplified above is to put all of your code into a library and then have the executable side depend upon that library. For instance, in this example the complete text of exe/Server.hs is
module Main where
import qualified HKTest as HK
main :: IO ()
main = HK.main
I am using ghc 7.6.3. I installed wxHaskell from here: https://github.com/wxHaskell/wxHaskell
It worked, the sample programs compile and the run successfully.
The only problem now is that I want to distribute a wxHaskell application on mac OS X. I tried using macosx-app and cabal-macosx (https://github.com/michaelt/cabal-macosx) to make an "app" file. It runs fine on my machine, but it fails to run on another computer. I get the following error:
Dyld Error Message: Library not loaded: /Users/user/.cabal/lib/wxc-0.90.1.0/ghc-7.6.3/libwxc.dylib.
I am using OS X 10.8.4 (Mountain Lion), but I would be also interested in compiling apps on Windows and redistribute them too.
What would be the best way to redistribute wxHaskell apps?
Setup.hs
-- Example Setup.hs for the wxHello app.
import Distribution.MacOSX
import Distribution.Simple
main :: IO ()
main = defaultMainWithHooks $ simpleUserHooks {
postBuild = appBundleBuildHook guiApps -- no-op if not MacOS X
}
guiApps :: [MacApp]
guiApps = [MacApp "WxHello"
(Just "resources/WxHello.icns")
Nothing -- Build a default Info.plist for the icon.
[] -- No other resources.
[] -- No other binaries.
ChaseWithDefaults -- Try changing to ChaseWithDefaults
]
wxHello.cabal:
Name: wxHello
Version: 0.1.0
Stability: Alpha
Synopsis: wxWidgets `Hello World' example for cabal-macosx
Description:
Example showing how to use cabal-macosx to build an application
bundle for a simple `Hello World' program using the wxWidgets GUI
toolkit.
Category: Data
License: BSD3
License-file: LICENSE
Copyright: Andy Gimblett <haskell#gimbo.org.uk>
Author: Andy Gimblett <haskell#gimbo.org.uk>
Maintainer: Andy Gimblett <haskell#gimbo.org.uk>
Build-Type: Custom
Cabal-Version: >=1.6
Executable WxHello
hs-source-dirs: src
Main-is: Main.hs
Build-Depends: base >= 3 && < 5, cabal-macosx, wx
ghc-options: -fwarn-tabs -threaded -Wall
Here are the dylib files inside the generated package:
WxHello.app $ find . | grep dylib
./Contents/Frameworks/Users/user/.cabal/lib/wxc-0.90.1.0/ghc-7.6.3/libwxc.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_baseu-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_baseu_net-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_baseu_xml-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_osx_cocoau_adv-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_osx_cocoau_aui-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_osx_cocoau_core-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_osx_cocoau_gl-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_osx_cocoau_html-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_osx_cocoau_propgrid-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_osx_cocoau_qa-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_osx_cocoau_ribbon-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_osx_cocoau_richtext-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_osx_cocoau_stc-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_osx_cocoau_webview-2.9.5.0.0.dylib
./Contents/Frameworks/Users/user/temp/wxWidgets-2.9.5/build-release/lib/libwx_osx_cocoau_xrc-2.9.5.0.0.dylib
./Contents/Frameworks/usr/lib/libc++abi.dylib
./Contents/Frameworks/usr/lib/libexpat.1.dylib
./Contents/Frameworks/usr/lib/libiconv.2.dylib
./Contents/Frameworks/usr/lib/libstdc++.6.dylib
./Contents/Frameworks/usr/lib/libz.1.dylib
The last redistributable I made in Windows with wxHaskell needed the files
mingwm10.dll and
wxmws28u_gcc.dll
to be in the same folder as the .exe (not just somewhere on my path).
This was using a previous version of wxHaskell, which compiled against a previous version of wxWidgits itself, so presumably you'd need the wx dll to have 29 in it rather than 28.
I compiled with static linking too:
ghc -static -optl-static -optl-mwindows Main -o Project.exe
the -optl-mwindows gets rid of the command prompt window which would otherwise appear alongside your app.
It might be helpful to include your .cabal and Setup.hs files.
From the documentation on cabal-macosx, it seems that you need to ensure that your MacApp data value in Setup.hs gets the appropriate mode for ChaseDeps (use ChaseWithDefaults instead of DoNotChase) in order to build redistributable app bundles.
If you have done that but still get the same error, I would check inside the resulting app bundle to see if the necessary libraries got copied in there at all. You may find enough information to file a bug with the cabal-macosx maintainer.
Edit
Based on what you've included, the setup looks correct, and it appears to have at least copied the library dependencies in. I think the problem is probably with the cabal-macosx package.
Looking at the source code to the dependency-fixup code, it looks like it should have printed a bunch of "Updating <library>'s dependence on <path> to <path>" lines as it was building the bundle. Did you see those? Were there any lines updating the binary itself?
I am not very experienced with the OS X linking process, but I would think that unless the binary is linked after copying the libraries, it would need to be updated as well. You should be able to use /usr/bin/otool -L <filename> and /usr/bin/install_name_tool to manually fix up the paths in binaries the install process may have missed.
Here are the man pages for those two tools:
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/install_name_tool.1.html
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/otool.1.html
I have simple program written with haskell, i build it with cabal. For example i my program has next directory structure:
my-prog
* Main.hs
* my-prog.cabal
* SomeDirWithHsFiles
- File1.hs
- File2.hs
I want that when i'll make cabal build and cabal install (maybe something else), SomeDirWithHsFiles with *.hs files, installed like a normal haskell library, and then i'll use File1.hs and File2.hs modules in other programm.
How can i do this?
Thank you.
You need to declare your additional files in a library section, like so:
library
exposed-modules: File1
File2
executable foo
main-is: Main.hs
See for example, xmonad's .cabal file.
I have a package with the following structure (okay, this is greatly simplified, but...)
app/
src/
Main.hs
data/
data.txt
app.cabal
Paths_app.hs
Setup.hs
In Paths_app.hs I have:
module Paths_app where
getDataFileName :: FilePath -> IO FilePath
getDataFileName = return
and in Main.hs I have:
module Main where
import Paths_app
main = do
file <- getDataFileName "data/data.txt"
data <- readFile file
putStrLn $ "Your data is: " ++ data
the relevant parts of my app.cabal file look like this:
name: app
version: 1.0
build-type: Simple
data-files: data/data.txt
executable foo
build-depends: base, haskell98
main-is: Main.hs
hs-source-dirs: src
This builds fine (using cabal configure followed by cabal install) but the executable complains that it can't find the data.txt file. I've tried replacing the line
file <- getDataFileName "data/data.txt"
with
file <- getDataFileName "data.txt"
but the same thing occurs. Is there something obvious I'm doing wrong?
I've tried to reproduce it, but it works fine for me.
In the setup you describe, I had to drop the dependency on haskell98 as both base and haskell98 were providing Prelude. Furthermore, the file Main wouldn't compile as it used the keyword data as a variable name, so I renamed the variable to dat. But then it worked just fine.
Some info on my setup:
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.4.1
$ cabal --version
cabal-install version 0.13.3
using version 1.14.0 of the Cabal library
$ ls ~/.cabal/bin/
... foo ...
$ ls ~/.cabal/share/app-1.0/data/
data.txt
The problem was that I was building on a Windows system, and when I used the filename returned by getDataFileName to load data into my program, I wasn't escaping the backslashes.