- cabal-devel - Haskell.org

HEADS UP: Windows Vista users
by Simon Marlow 12 Apr '07

12 Apr '07

I've discovered a gotcha that happens when trying to use Cabal on Windows Vista. If you compile Setup.lhs to a binary (as I often do), with something like 'ghc --make Setup', and then try to run it, you'll get something like this: $ ./Setup configure Setup.exe: Permission denied This is due to a highly dubious security "feature" in Vista whereby it detects that you might be trying to run an installer-type program and refuses to execute the binary without elevated permissions. The idea is that ordinary users won't be confused when their installer fails partway through due to insufficient permissions. Unfortunately this works by matching on the name of the binary(!!!!), so names like "setup", "install" etc. are affected (there isn't a complete list, apparently). Other casualties are: * cabal-setup (compiles Setup.hs to setup.exe) * The GHC build system, which now uses Cabal * 'make install', which runs /usr/bin/install.exe More details in this MSDN thread: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1021146&SiteID=1 and this Cygwin thread: http://www.cygwin.com/ml/cygwin/2006-12/msg00518.html Fortunately you can turn off the behaviour: Start->Run->secpol.msc, then Security Settings -> Local Policies -> Security Options ! UAC: Detect application installations and prompt for elevation. It appears you need to reboot for the change to take effect. The right workaround is to add a manifest to the binary asking for no security elevation, apparently this is quite easy. We'll need to get GHC to do this for every binary it generates in the future. For now, I'll put a note in the building guide and FAQ, and make a ticket for GHC 6.6.2 to do the manifest thing. Cheers, Simon

1 0

Setup sdist broken on Windows
by Neil Mitchell 10 Apr '07

10 Apr '07

Hi, On Windows, taking the filepath library: Building source dist for filepath-1.0... copy System\FilePath.hs to dist\src\filepath-1.0\.\System\FilePath.hs copy System\FilePath\Posix.hs to dist\src\filepath-1.0\.\System\FilePath\Posix.h s copy System\FilePath\Windows.hs to dist\src\filepath-1.0\.\System\FilePath\Windo ws.hs copy System\FilePath\Internal.hs to dist\src\filepath-1.0\System\FilePath\Intern al.hs copy Setup.hs to dist\src\filepath-1.0\Setup.hs copy filepath.cabal to dist\src\filepath-1.0\filepath.cabal D:\bin\tar.exe -C dist\src -czf dist\filepath-1.0.tar.gz filepath-1.0 D:\bin\tar.exe: Cannot use compressed or remote archives D:\bin\tar.exe: Error is not recoverable: exiting now Setup: source tarball creation failed! Tar exited with status 2 Using Cabal from about 2 minutes ago. Any idea what is wrong? Thanks Neil

2 1

Building Projects under mingw that use c2hs [apologies for repost; archive seemed to scrub text portion, see archive for attached file]
by Alexander McPhail 07 Apr '07

07 Apr '07

Hi, I have been trying to build a Cabal package that uses c2hs under mingw and have run into some problems. 1) c2hs needed its own options because it has to pass a flag to its invocation of the CPP. I have already submitted this patch. (I also noticed a request for cppOptions in the Cabal.cabal file, so I added that) 2) When c2hs generates the foreign import ccall unsafe "path/to/include.h function" :: Type it doesn't insert the appropriate number of path separators for windows ( i.e. \\ not \) I have this patch sitting in my copy of c2hs. But what I did is really ugly: at around line 567 (process :: FilePath -> FilePath -> CST s ()) I inserted: > outFName' <- getSwitch outputSB > -- on windows the path separator needs to be "\\" not "\" > let outFName = replaceFileSeparator outFName' where replaceFileSeparator is defined as: > replaceFileSeparator :: String -> String > replaceFileSeparator [] = [] > replaceFileSeparator (x:xs) > | x == '\\' = "\\\\" ++ (replaceFileSeparator xs) > | otherwise = x : (replaceFileSeparator xs) this fixes the problem but stinks. 3) when compiling my c2hs generated .hs file, the c2hs generated .h file is not being found. $ ./Setup.lhs -v build Reading parameters from D:\Apps\MSYS\1.0\local\src\mingw-c2hs-cabal-test\cabal-root\mingw- c2hs-cabal-test.buildinfo Preprocessing library Mingw-c2hs-cabal-test-0.0.1... D:\Apps\MSYS\1.0\local\bin\c2hs.exe -C -D__GLASGOW_HASKELL__=606 -C -I..\include --cppopts=-I../include --include=src -o src\Cabal\MingwTest.hs src\Cabal\MingwTest.chs D:\Apps\MSYS\1.0\local\bin\c2hs.exe -C -D__GLASGOW_HASKELL__=606 -C -I..\include --cppopts=-I../include --include=src -o src\Cabal\MingwTest2.hs src\Cabal\MingwTest2.chs Building Mingw-c2hs-cabal-test-0.0.1... d:\Apps\ghc\ghc- 6.6\bin\ghc.exe -package-name Mingw-c2hs-cabal-test-0.0.1--make -hide-all-packages -i -idist\build\autogen -i. -isrc -I..\include -#include "test.h" -odir dist\build -hidir dist\build -package base-2.0 -O -package haskell98 -fglasgow-exts -fffi Cabal.MingwTest Cabal.MingwTest2C2HS [1 of 3] Compiling C2HS ( src/C2HS.hs, dist\build/C2HS.o ) [2 of 3] Compiling Cabal.MingwTest ( src/Cabal/MingwTest.hs, dist\build/Cabal/MingwTest.o ) C:\DOCUME~1\vivian\LOCALS~1\Temp\ghc31772_0\ghc31772_0.hc:6:33: src\Cabal\MingwTest.h: No such file or directory I have attached a set of files that will generate the errors I have mentioned on mingw. Cheers, Vivian

1 0

Building Projects under mingw that use c2hs
by Alexander McPhail 07 Apr '07

07 Apr '07

Hi, I have been trying to build a Cabal package that uses c2hs under mingw and have run into some problems. 1) c2hs needed its own options because it has to pass a flag to its invocation of the CPP. I have already submitted this patch. (I also noticed a request for cppOptions in the Cabal.cabal file, so I added that) 2) When c2hs generates the foreign import ccall unsafe "path/to/include.h function" :: Type it doesn't insert the appropriate number of path separators for windows (i.e. \\ not \) I have this patch sitting in my copy of c2hs. But what I did is really ugly: at around line 567 (process :: FilePath -> FilePath -> CST s ()) I inserted: > outFName' <- getSwitch outputSB > -- on windows the path separator needs to be "\\" not "\" > let outFName = replaceFileSeparator outFName' where replaceFileSeparator is defined as: > replaceFileSeparator :: String -> String > replaceFileSeparator [] = [] > replaceFileSeparator (x:xs) > | x == '\\' = "\\\\" ++ (replaceFileSeparator xs) > | otherwise = x : (replaceFileSeparator xs) this fixes the problem but stinks. 3) when compiling my c2hs generated .hs file, the c2hs generated .h file is not being found. $ ./Setup.lhs -v build Reading parameters from D:\Apps\MSYS\1.0\local\src\mingw-c2hs-cabal-test\cabal-root\mingw- c2hs-cabal-test.buildinfo Preprocessing library Mingw-c2hs-cabal-test-0.0.1... D:\Apps\MSYS\1.0\local\bin\c2hs.exe -C -D__GLASGOW_HASKELL__=606 -C -I..\include --cppopts=-I../include --include=src -o src\Cabal\MingwTest.hs src\Cabal\MingwTest.chs D:\Apps\MSYS\1.0\local\bin\c2hs.exe -C -D__GLASGOW_HASKELL__=606 -C -I..\include --cppopts=-I../include --include=src -o src\Cabal\MingwTest2.hs src\Cabal\MingwTest2.chs Building Mingw-c2hs-cabal-test-0.0.1... d:\Apps\ghc\ghc-6.6\bin\ghc.exe -package-name Mingw-c2hs-cabal-test-0.0.1--make -hide-all-packages -i -idist\build\autogen -i. -isrc -I..\include -#include "test.h" -odir dist\build -hidir dist\build -package base-2.0 -O -package haskell98 -fglasgow-exts -fffi Cabal.MingwTest Cabal.MingwTest2C2HS [1 of 3] Compiling C2HS ( src/C2HS.hs, dist\build/C2HS.o ) [2 of 3] Compiling Cabal.MingwTest ( src/Cabal/MingwTest.hs, dist\build/Cabal/MingwTest.o ) C:\DOCUME~1\vivian\LOCALS~1\Temp\ghc31772_0\ghc31772_0.hc:6:33: src\Cabal\MingwTest.h: No such file or directory I have attached a set of files that will generate the errors I have mentioned on mingw. Cheers, Vivian

1 0

Building individual programs
by allan 06 Apr '07

06 Apr '07

Dear all I have a cabal package which defines in the cabal package several programs to be built such as: Executable: prog1 Main-is: examples/Prog1.hs Ghc-options: -Wall Executable: prog2 Main-is: examples/Prog2.hs Ghc-options: -Wall It's actually a library and the individual programs are a bunch of examples. When I work on one of these individually it's mildly annoying that runhaskell Setup.hs build builds all of them. I'd quite like to be able to do something like: runhaskell Setup.hs build prog1 or even just runhaskell Setup.hs prog1 to build only the first example. I know about the "Buildable" field in the cabal file, but I was kind of hoping there was a way to do this such that the cabal file doesn't need to be continually modified (and runhaskell Setup.hs configure --..... re-run). So is there a (standard) way to do this? If not, I suppose the best way to do it would be in the Setup.hs file, ie could do something like: processArgs :: [ String ] -> IO () processArgs [ "prog1" ] = <Something to build prog1 with all the configuration information> processArgs _ = defaultMainWithHooks myHooks if this is the best way, what should I have in the <Something .. > bit? regards allan

1 0

Let's play Name That Extension!
by Stefan O'Rear 31 Mar '07

31 Mar '07

A large number of the newer GHC extensions have no cabal name. This is a very bad situation because if Hugs/yhc/etc were to gain support for (say) GADTs, it would not be possible to run cabal programs that require them, since the way programs specify dependency is with -fglasgow-exts. Also, what is the protocol for requesting cabal extension names? I've many Cool Extension Ideas for my haskeell impl project (nowhere near done). Stefan

2 4

[PATCH] Check the exit code from tar
by Bryan O'Sullivan 27 Mar '07

27 Mar '07

Prior to this change, if tar failed, the sdist command would fail to notice. <b

2 1

Cabal and RPM redux
by Bryan O'Sullivan 27 Mar '07

27 Mar '07

Since my last attempt to add RPM support didn't go anywhere, I'd like to figure out what's a good way to make progress. If I were to contribute a standalone program called cabal-rpm (just as cabal-install is a standalone program), would that be acceptable to add to the darcs repo? <b

3 3

Re: Extensions and Cabal
by Stefan O'Rear 24 Mar '07

24 Mar '07

On Sat, Mar 24, 2007 at 06:29:56PM -0500, Samuel Bronson wrote: > On 3/24/07, Stefan O'Rear <stefanor(a)cox.net> wrote: > > >> The only thing I can think of (besides "nice idea") is that you'd better > >either > >> a) make sure that Cabal always knows about all the extensions supported > >by the > >> compiler > >> or > >> b) provide a workaround for when Cabal does not know about a given > >extension. > > > >We already have this, it's called darcs send. > > > >That said, cabal is very sorely lacking hacker's documentation. I for > >one can't understand the code. (yet (but still I learned lambdabot > >faster)) > > So, how do you compel the people who do compiler releases to ensure > that it is *done*? > > Also, what about the part where you have to wait for another Cabal > release? I was going to write a nice rebuttal here, but then I remembered I hadn't read the original message well enough. Having done so, I agree with Ian completely. (*Great* idea, I had the same one for the hv system.) Stefan

1 0

Extensions and Cabal
by Ian Lynagh 24 Mar '07

24 Mar '07

Hi Cabalites, I fear this may be contentious, but here goes anyway... Currently we have (at least) 4 ways that extension E can be enabled for a given file in a cabal package (using GHC as an example, if -fe enables E): 1. foo.cabal: Extensions: E 2. foo.cabal: Ghc-Options: -fe 3. Foo.hs: {-# LANGUAGE E #-} 4. Foo.hs: {-# OPTIONS_GHC -fe #-} Ideally, from cabal's point of view, we would use option 1. This way cabal knows about the extensions, so can fail early if we don't support the necessary extensions to build something. 2 and 4 are inferior variants of 1 and 3 respectively; the only case I can think of where you might want to use them is if cabal doesn't know about the extension yet. This could be solved by a --language=E flag that GHC treats identically to -fe. Obviously cabal can't check that GHC supports this extension in advance (so would have to assume that it does), but at least we no longer have any need to enable extensions with method 2 or 4. We could also then have Cabal always pass a --no-extension-flags flag, which would mean that GHC would reject -fe. That wasn't the contentious bit, so hopefully you aren't too inflamed yet! Suppose we agree that we should only use method 1; there are a number of issues: * If someone uses method 3, no alarm bells will sound. The package will continue to build where it can be built. * The same set of extensions is used for every module. For example, if you want to allow overlapping instances in one particular place[1] then you must allow them everywhere. * If you want to load one of the modules in ghci, say, then you need to tell it what flags to use. Thus I propose that the .cabal file actually specifies what extensions the modules are /allowed/ to use, but does not actually enable them. They would then be enabled by LANGUAGE pragmas in the modules as necessary. So, if the .cabal file says "Extensions: E, F" then the modules will be compiled with --no-extension-flags --allowed-extension=E,F and if a module has "{-# LANGUAGE E #-}" then only extension E would be enabled for that module. If a module has "{-# LANGUAGE E,G #-}" then compilation would fail as extension G is not permitted. Any comments? Criticisms? Flames? Thanks Ian [1] Currently we can only specify this to a file-level granularity, but in principle you could imagine more localised pragmas, like we have for unboxed fields.

6 6