- cabal-devel - Haskell.org

noinst executables?
by Conrad Parker 24 Aug '06

24 Aug '06

Hi, I'm using HUnit with Cabal: specifying test programs to be built and then run with 'runTests'. However, the test programs are marked as normal executables, and hence are installed by ./Setup.hs install. This isn't necessary, and clutters the installation; is there any way yet to mark executable targets as "not for installation" ("noinst" in GNU autotools terms)? cheers, Conrad.

2 1

install doesn't install under Windows
by Neil Mitchell 24 Aug '06

24 Aug '06

Hi Under Windows, for an application, with the example of Alex: runhaskell Setup configure runhaskell Setup build runhaskell Setup install This however doesn't result in an Alex binary that can be found by Cabal, i.e. to build Haddock. So there are a few options: 1) Move alex.exe into some global Haskell directory for binaries (which is on the PATH) 2) Make an alex.bat in some global Haskell binary directory (on the PATH) 3) Make Cabal detect wherever it puts alex, so it can then use it. 4) Put whereever it puts alex on the PATH. All have plus and minus points, I'd lean to 1 (since thats what I already do when installing things). Thanks Neil

4 8

darcs patch: Export all the modules packge.conf.in
by Esa Ilari Vuokko 21 Aug '06

21 Aug '06

Hi, I recently ran into issue I couldn't use Compat.FilePatch with Cabal built in GHC build-tree (ie using Makefiles) Fri Aug 18 00:27:20 FLE Standard Time 2006 Esa Ilari Vuokko <ei(a)vuokko.info> * Export all the modules package.conf.in This simple patch just exports all the modules even when building with makefiles, just like we do in Cabal.cabal Best regards, --Esa New patches: [Export all the modules package.conf.in Esa Ilari Vuokko <ei(a)vuokko.info>**20060817212720 We don't hide them in Cabal.cabal either, and atleast FilePath is usefull for client applications. ] { hunk ./package.conf.in 40 - -hidden-modules: } Context: [repair Distribution.Compat.Map for non-GHC Ross Paterson <ross(a)soi.city.ac.uk>**20060810124314] [Avoid use of deprecated Data.FiniteMap, if possible Simon Marlow <simonmar(a)microsoft.com>**20060809153232 Distribution.Compat.Map taken from Haddock. ] [Change 'getInstalledPkg' to the more sensible 'getLatestPkg'. Lemmih <lemmih(a)gmail.com>**20060806135545] [Don't check for packagesDirName and servListFile, they may not exist. Lemmih <lemmih(a)gmail.com>**20060806135423] [GHC build only: set $(MKDEPENDHS) in addition to $(HC) Simon Marlow <simonmar(a)microsoft.com>**20060803092216] [pass the whole packageId to GHC with the -package-name flag Simon Marlow <simonmar(a)microsoft.com>**20060720150931 This shouldn't make any difference to current GHC's, but will be required by the new GHC package code. ] [install: pass the verbose flag to register too Simon Marlow <simonmar(a)microsoft.com>**20060728085914] [Add documentation of new LocalBuildInfo fields Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk>**20060726230130] [Wrap excessively long line Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk>**20060726221702] [Hold back on forcing vanilla libs for TH for the moment Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk>**20060726221532 When we get confirmation from GHC devs that it's the right thing to do then we can add it in. ] [Add initial support for --enable/disable-library-vanilla flags jeremy.shaw(a)linspireinc.com**20060720174408 For additional information see these mail threads: http://www.haskell.org//pipermail/libraries/2006-July/005522.html http://urchin.earth.li/pipermail/debian-haskell/2006-July/000220.html ] [build and install cabal-setup as part of GHC build Simon Marlow <simonmar(a)microsoft.com>**20060720140417] [fix indentation in do block for H'98 compatibility Malcolm.Wallace(a)cs.york.ac.uk**20060711162221] [resolve conflicts from henning-thielemann's work. Thanks Henning! ijones(a)syntaxpolice.org**20060708185016] [install Haddock documentation in share/package/doc/html and register that path in the ghc-pkg cabal(a)henning-thielemann.de**20060609194058] [PackageDescription: haddockName generates the name of the .haddock file cabal(a)henning-thielemann.de**20060609193924] [PackageDescription: added toMaybe, some logical simplifications cabal(a)henning-thielemann.de**20060609193508] [Distribution.Simple.Utils: copyDirectoryRecursiveVerbose cabal(a)henning-thielemann.de**20060609192715] [Distribution.Compat.Directory: added getDirectoryContentsWithoutSpecial cabal(a)henning-thielemann.de**20060609192421] [Distribution.simple: haddock option --use-package tells which packages to hyperlink to cabal(a)henning-thielemann.de**20060605183304] [stripPrefix -> dropPrefix cabal(a)henning-thielemann.de**20060604195549] [generate .haddock interface file when running haddock cabal(a)henning-thielemann.de**20060604195216] [UNDO: Merge "unrecognized long opt" fix from 6.4.2 Simon Marlow <simonmar(a)microsoft.com>**20060705142842 This patch undid the previous patch, "merge from base". I asked Sven to revert it, but didn't get an answer. See GHC bug #473. ] [Change flags passed to hsc2hs Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk>**20060704001926 The extra-libraries must be passed as -L-l${lib} or linking the C prog that hsc2hs generates may fail if any symbols are referenced. Also can't use cppOptions function since hsc2hs doesn't support -U. Need to do -U flags in ccOptions seperately. ] [finish interaction with remote HTTP servers audreyt(a)audreyt.org**20060624233156] [stage 2 patch: implement the "list" command audreyt(a)audreyt.org**20060624231421] [it's now 00-latest not latest audreyt(a)audreyt.org**20060624221907] [implement support for flat-file layout audreyt(a)audreyt.org**20060624221547] [parsec is not a dependency Simon Marlow <simonmar(a)microsoft.com>**20060518131434 It is apparently required for the wash2hs test, however. ] [Merge "unrecognized long opt" fix from 6.4.2 Sven Panne <sven.panne(a)aedion.de>**20060506110640] [Cabal.xml: entity greencard was mixed up with haddock cabal(a)henning-thielemann.de**20060411161212] [Change calls to 'make' into '$(MAKE)' Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk>**20060502174630 This is the portable thing to do and fixes things on FreeBSD where make/=gmake ] [Hugs: copy paths module to the right place, this time Ross Paterson <ross(a)soi.city.ac.uk>**20060503132510] [pass correct -P flag to ffihugs Ross Paterson <ross(a)soi.city.ac.uk>**20060503122452 The -P flag wasn't superfluous, but it was wrong for executables. ] [Hugs: copy path module into package build dir Ross Paterson <ross(a)soi.city.ac.uk>**20060503122300] [add header file for GetModuleFileNameA Ross Paterson <ross(a)soi.city.ac.uk>**20060502141641] [remove superfluous ffihugs -P option Ross Paterson <ross(a)soi.city.ac.uk>**20060502104635] [fix for Hugs Ross Paterson <ross(a)soi.city.ac.uk>**20060502101054 Add explicit types for a couple of constants to work around Hugs's imperfect implementation of the monomorphism restriction. ] [TAG 1.1.4 duncan.coutts(a)worc.ox.ac.uk**20060502095901] [TAG shipped in GHC 6.4.2 Simon Marlow <simonmar(a)microsoft.com>**20060424093133] [Hugs: also compile the paths module Ross Paterson <ross(a)soi.city.ac.uk>**20060501171206] [markup fix Ross Paterson <ross(a)soi.city.ac.uk>**20060501145015] [move cabal-install/etc-cabal-get to cabal-install/etc-cabal-install alson(a)alsonkemp.com**20060430175158] [Complete move of cabal-get to cabal-install + some fixups alson(a)alsonkemp.com**20060430174300] [basic information for installing ijones(a)syntaxpolice.org**20060430063205] [build and install cabal-setup ijones(a)syntaxpolice.org**20060430063144] [add etc-cabal-get as a data-file ijones(a)syntaxpolice.org**20060430055332] [bumping cabal version number. 1.1.4 will be the one released with ghc 6.4.2. ijones(a)syntaxpolice.org**20060430044905] [modify makefile for cabal-install ijones(a)syntaxpolice.org**20060430041617] [cabal-get will become cabal-install ijones(a)syntaxpolice.org**20060430025633] [getting rid of cabal-install in favor of cabal-get ijones(a)syntaxpolice.org**20060430024951] [Remove erroneous exports... alson(a)alsonkemp.com**20060428195702] [Patch to fix "-ixyz" being overwritten by "-i" and to remove Cabal's dependency on the Cabal package. alson(a)alsonkemp.com**20060428055353] [Separate build into "make build" and "make install" alson(a)alsonkemp.com**20060428034151] [Fixups to get cabal-get into Cabal alson(a)alsonkemp.com**20060428032617] [Update Cabal with cabal-get alson(a)alsonkemp.com**20060427204050] [Fix JHC command lines. Einar Karttunen <ekarttun(a)cs.helsinki.fi>**20060427005922] [document install-includes and register --inplace Simon Marlow <simonmar(a)microsoft.com>**20060428130542] [fix imports for Windows simonmar(a)microsoft.com**20060428075617] [Better support for packages that need to install header files Simon Marlow <simonmar(a)microsoft.com>**20060426140627 There's a new field for .cabal files: install-includes: foo.h bar.h This means the same as 'includes', except that the files named therein will be installed into $libdir/include. 'includes' should only be used for headers already installed on the system. Directories listed in 'include-dirs' still turn into -I options for hsc2hs, cpphs, and C compilations. However, for installation purposes, relative directories in 'include-dirs' are now treated differently from absolute directories: - an absolute directory is copied to the include-dirs field of the installed package config - files names in install-includes are assumed to be found in one of the *relative* directories listed in include-dirs So the common pattern for providing a header file that you want to be available everywhere including to via-C compilations against this package: include-dirs: myincludes install-includes: foo.h will install the header file myincludes/foo.h in $libdir/include/foo.h. ] [merge from base: Simon Marlow <simonmar(a)microsoft.com>**20060426121408 Wed Apr 26 13:11:10 BST 2006 Simon Marlow <simonmar(a)microsoft.com> * RequireOrder: do not collect unrecognised options after a non-opt ] [pass unrecognised options before the command name to the command Simon Marlow <simonmar(a)microsoft.com>**20060426121321 Previously, options before the command name other than --help were just ignored, which is quite confusing behaviour. So now, ./setup --with-compiler=ghc-6.4.2 configure works as you expect, instead of ignoring the --with-compiler option. ] [First attempt at a cabal-setup command Simon Marlow <simonmar(a)microsoft.com>**20060303162233 cabal-setup is a replacement for 'runhaskell Setup.hs'. It accepts exactly the same commands. Additionally, the following new features are provided: * Setup.{hs,lhs} is optional. If omitted, cabal-setup behaves just like Distribution.Simple.defaultMain. * If the .cabal file contains a cabal-version field, then Setup.hs is built using an appropriate version of Cabal. This might entail creating Setup.hs if it doesn't exist. * cabal-setup interprets the options --with-compiler and --with-hc-pkg to determine the compiler used to compile Setup.hs. Later, we could add support for building multiple packages in dependency order, as per recent discussions on libraries(a)haskell.org. ] [add new modules Ross Paterson <ross(a)soi.city.ac.uk>**20060425195548] [Implement "setup register --inplace", and a few other minor things Simon Marlow <simonmar(a)microsoft.com>**20060425144733 There are a few changes in this patch: - New flag to register, --inplace. "setup register --inplace" registers the package for use in the build tree, i.e. without installing. It works with GHC only, currently. - The parameters to RegisterCmd, UnregisterCmd and InstallCmd are a legacy from before the time of hooks (or something) and don't serve any purpose any more, AFAICT. So I removed them. - I don't think "setup register" worked propertly before if --user was given to configure. It does now. - New flag to register: --with-hc-pkg (just the same as when given to configure, but lets you override it at register-time) ] [Refactoring only: separate compiler-specific simple build implementation Simon Marlow <simonmar(a)microsoft.com>**20060425111957] [get LocalBuildInfo from Distribution.LocalBuildInfo Simon Marlow <simonmar(a)microsoft.com>**20060425111921] [warning cleanup Simon Marlow <simonmar(a)microsoft.com>**20060425102302] [Distribution.Compat.FilePath should be hidden Simon Marlow <simonmar(a)microsoft.com>**20060411141305 This also matches package.conf.in. ] [Hide Distribution.GetOpt; it just re-exports System.Console.GetOpt anyway Simon Marlow <simonmar(a)microsoft.com>**20060411141045 This also matches Cabal.cabal. ] [GHC FFI flag should be -fffi not -ffi, the latter merely happens to work. Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk>**20060318022010] [Make ghc-6.2 packages be exposed by default. Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk>**20060221135026 For ghc-6.4 when Cabal registers packages it exposes them by default. However it does not do the same fo ghc-6.2. This change corrects the discrepancy. This patch is already being used in Gentoo with Cabal 1.1.3. ] [test case for buildinfo with multiple executables ijones(a)syntaxpolice.org**20060408213048] [It is no longer necessary to run 'configure' before 'clean' or 'sdist', addressing http://haskell.galois.com/trac/hackage/ticket/12. Nick Alexander <ncalexan(a)uci.edu>**20060404054127 In order to change this behaviour, it was necessary to modify the hook interface, specifically cleanHook, postClean, sDistHook, postSDist. They now take a Maybe LocalBuildInfo, since a LocalBuildInfo might not be available in .setup-config. ] [windows patch from brian.mabry.edwards(a)gmail.com ijones(a)syntaxpolice.org**20060404171731] [oops, don't enable -split-objs by default Simon Marlow <simonmar(a)microsoft.com>**20060314124358] [export configDependency Simon Marlow <simonmar(a)microsoft.com>**20060303155527] [comment fix Simon Marlow <simonmar(a)microsoft.com>**20060303155516] [don't check cabal-version during parsing, it doesn't work Simon Marlow <simonmar(a)microsoft.com>**20060303155500 because parsers are evaluated multiple times due to backtracking. ] [no need to use a verbatim copy of System.Console.GetOpt, omit if possible Simon Marlow <simonmar(a)microsoft.com>**20060303144025] [Support for -split-objs with GHC Simon Marlow <simonmar(a)microsoft.com>**20060302170907 New configure option: --enable-split-objs creates libraries using -split-objs with GHC (current HEAD or later only, the configure checks for version 6.5). Fixes ticket #19. ] [Initial support for JHC Einar Karttunen <ekarttun(a)cs.helsinki.fi>**20060206233543] [added some fields to test suite for duncan's mods ijones(a)syntaxpolice.org**20060204223256] [fixup PackageDescription test code Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk>**20060201183912 just ignore the extra ParseOk warnings field ] [ignore "x-" extension fields without a warning Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk>**20060201183145] [Make unknown fields a warning rather than an error Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk>**20060201182944 Add support for warnings to the ParseResult type. Change existing warnings from using Debug.Trace to use this new warning support. ] [fix conflict Simon Marlow <simonmar(a)microsoft.com>**20060206095833] [push and pull all ijones(a)syntaxpolice.org**20060201185441] [combine GNUmakefile and Makefile Simon Marlow <simonmar(a)microsoft.com>**20060206095400] [now build Setup.lhs instead of using runghc on it. still uses runhugs. ijones(a)syntaxpolice.org**20060130054810] [cabal-install uses defaultMain if it can't find Setup.lhs ijones(a)syntaxpolice.org**20060130050710] [cleaned up suffix handler params to hooks ijones(a)syntaxpolice.org**20060116064811 Summary if last few changes: I modified the hooks interface quite a bit, again. There's good news and bad news about this. The good news is that it's cleaned up and should be easier to maintain and to avoid future modifications. The bad news is that this change itself will break stuff, of course. If you have any trouble building your Setup scripts, please let me know. I really think that it was best to bite the bullet right now in one big go instead of down the road with lots of little changes. I have a lot more confidence in the hooks interface, and I don't actually expect that it'll change as often. I made the types more consistent, and made sure there are accessor functions on each of the Flags types so that if the flags types change in the future, it shouldn't break lots of code. Another piece of good / bad news is that I decided not to get rid of the pre & post hooks. They are nice for convenience and it wouldn't be nearly so easy to write hooks without them. That's bad because the interface to hooks is still pretty big, which means that there's more likelihood that it'll change in the future. Another weakness in the Hooks interface is that with command hooks (like sDistHook) it's tempting to add parameters to them; basically the stuff that we compute between the preSDist and sDist hook. I removed such params and have their values computed elsewhere. Cabal hackers, please avoid adding parameters to these command hooks if at all possible in order to keep the interface steady. If you need to compute a value to pass to these functions, compute it in the function and / or make it available as a function that someone crafting hooks can use as well, or consider whether it belongs in one of the parameters already being passed to the hooks, PackageDescription, LocalBuildInfo, UserHooks, Flags. ] [make the order of params to cmd hooks consistent ijones(a)syntaxpolice.org**20060116055858] [remove some flags from sdist, some cleanup ijones(a)syntaxpolice.org**20060116053818] [clarifying and making flags types consistent ijones(a)syntaxpolice.org**20060116035033] [changing tuple types to records w/ fields ijones(a)syntaxpolice.org**20060115234317] [moving TODO stuff to wiki ijones(a)syntaxpolice.org**20060115234303] [fix version number in fptools makefile to match .cabal file ijones(a)syntaxpolice.org**20060201183331] [Add extraGHCiLibraries to the InstalledPackageInfo and extend the parser. Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk>**20060131163640] [re-add the GNUmakefiles Simon Marlow <simonmar(a)microsoft.com>*-20060123115236 These are now safe after we added "-f Makefile" to the make args when invoked from the GHC build system. This repo should now be useable as the main Cabal repo. ] [re-add the GNUmakefiles Simon Marlow <simonmar(a)microsoft.com>**20060123115236 These are now safe after we added "-f Makefile" to the make args when invoked from the GHC build system. This repo should now be useable as the main Cabal repo. ] [TAG checkpoint simonmar(a)microsoft.com**20060113152542] Patch bundle hash: 404684fddc759aeb78516c4b902e1d6658b4c29a

3 4

Cabal/GHC interaction buglet
by Neil Mitchell 21 Aug '06

21 Aug '06

Hi, Using GHC 6.4.2, Cabal from Darcs - every time I do runhaskell Setup build in Hoogle (the Hoogle cabal file isn't up on the web yet, but I'm working on it!) it does relinking. Trying -v I get the command: Building Hoogle-3.0... C:\ghc\ghc-6.4.2\bin\ghc.exe -Idist\build -o dist\build\hoogle\hoogle --make -hi de-all-packages -i -idist\build\autogen -isrc -odir dist\build\hoogle\hoogle-tmp Unfortunately GHC 6.4.2 has a bug in it that if the .exe is not specified in the -o it always relinks. Any chance Cabal can ++ executableExtension when passing onto the GHC? (I did take a look at writing a patch, but as far as I can see in Distribution.Simple.GHC, the file passed along to -o is created by mkGHCiLibName and should end in ".o", but it doesn't... If anyone can point me at where this should go, then maybe, just maybe...) Thanks Neil

3 5

Re: Cabal patch: Add setup haddock --hoogle option
by Henning Thielemann 21 Aug '06

21 Aug '06

On Sun, 20 Aug 2006, Neil Mitchell wrote: > Hi, > > The attached patch adds support for the --hoogle option to the haddock target. > > Tested on the base package, now running: > > runhaskell Setup haddock --hoogle > > Gives the file base-2.0.txt which can then be fed into Hoogle properly. Is it a good idea to tell this by an option to 'Setup haddock'? This means manual intervention on each package which shall be used by Hoogle.

2 1

Re: Extending Windows support
by Krasimir Angelov 21 Aug '06

21 Aug '06

Hi Esa, All these things are really useful for all Windows developers. I didn't yet proposed this only because it is too Windows and GHC specific but this isn't a reason not to have them. Actually if we have support for resources in Cabal then one day I would like to see resource editor in Visual Studio for Haskell. One interesting feature would be to have automatic generation for VERSION resource that to be prepopulated with the version and copyright information from Cabal. We already have generation for one Haskell module why not to have generation for one resource file. You propose to extend the cabal description with one additional stanza type like the executable stanzas but I would recall that the current model with one library and multiple executables is broken. I vote again for a redesign where to have only one library or one executable in a given package. After that with the addition of DLL we will have three types of packages: library, executable or DLL. I didn't looked at implementation but I saw a couple of messages in this mailing list about the introduction of configurations in Cabal. Are they working with executables? Cheers, Krasimir > Esa Ilari Vuokko <eivuokko(a)gmail.com> writes: > > > Hi, > > > > There's few things Cabal could handle for Windows-based Cabal users. > > I hope to implement them if there's agreement that they are sensible > > additions into Cabal. All of them can of course be done in Setup.hs, > > but that's just annoying. > > > > This is rather ghc-specific, because that's what I use. And most of > > this doesn't probably matter for compilers that aren't producing > > binaries. > > > > * DLLs > > Rationale: Building DLLs is fairly common in Windows, they are a > > most common way to extend many appliations via COM or other > > plugin-like systems. Note: this has nothing to do with producing > > dynamically linked haskell packages/libs. Rather it almost > > identically to producing .exe, except that main won't be called. > > > > Todo: Easiest way seems to be to add new part to package config, > > much like executables, extending executable-list to contain DLL > > info might also be doable, but less clean. Important bits I can > > think of: > > * passing --mk-dll to ghc > > * being able to specify .def file and passing it through ghc to > > dlltool (--optdll--def --optdllPATH/TO/A.DEF) > > * Possibly building import library by calling dlltool with .def > > and right options (means we have to add new program: dlltool) > > * Installing import lib...well dunno about this. > > > > Example how it can be done right now: > > http://darcs.haskell.org/vshaskell/vs_haskell/Setup.lhs > > (note that this script builds import lib for diffrent dll than it builds) > > > > * Resource (scripts) > > Rationale: Resources are embedded (binary) data sections in executables. > > In Windows these can be (easily) edited after the exectuable has been > > linked, and there's many APIs that can use them. Also some important > > information can be encoded in them, like versioning, icons, manifest > > files. I am not sure about already compiled resource files, I recall > > some dialogeditors producing object files, but they are probably wrong > > format object files as long as ghc works on top of gnu toolchain. > > > > Todo: Mainly Cabal needs to know and invoke a tool very much like > > c-compiler. For mingw (and probably cygwin) this would be windres.exe. > > We probably also need to get the tool into ghc binary distribution. > > > > Example: I don't know anyone doing this using Cabal. > > > > Best regards, > > --Esa Ilari Vuokko > > _______________________________________________ > > cabal-devel mailing list > > cabal-devel(a)haskell.org > > http://www.haskell.org/mailman/listinfo/cabal-devel >

1 0

New index format patch
by Paolo Martini 20 Aug '06

20 Aug '06

Hello, OK good news! Here's a patch to make cabal-install use the tarball index format discussed in the previous email. (I finally gave up in trying to do a whole refactoring, which I started from scratch many times, and started a more seamless integration of ideas in the existing code.) Since we don't rely on any program to do the QA, check that the packagename directory and the name of the tarball and the name inside the .cabal file are the same case-sensitively before adding it. The instructions for those eager of making a repository: 1. mkdir -p packages/packagename 2. cp package-version.tar.gz packages/packagename/ 3. GOTO 1 for each package you want in the repository 4. tar --create --gzip --file packages/00-index.tar.gz --exclude '*.tar.gz' --directory packages/ . # don't miss the last dot in the above command! I need help on one matter--I am not sure about pkgUrl: If I enable multiple repositories and scan the local hierarchy after having downloaded the files from all of them, it becomes impossible to map files to urls. So the solution could be having multiple repositories whose names are the urlEncoded strings of the actual repositories' urls. If having just one repository doesn't bother anyone too much, I'd like to know what do you think it's worth doing next. Also, I'd like to have some feedback on this patch, I am not sure I did not make any mistake! Peace, Paolo. P.S. Lemmih, I did make the little modification to TarUtils.extractTarFile dcoutts suggested, do you think it is okay? Another possibility could be passing the directory to `cd' to, via the -C option, I'd like to hear what you think. --

2 1

Re: Building cabal with cabal fails?
by shelarcy 20 Aug '06

20 Aug '06

On Thu, 17 Aug 2006 21:48:13 +0900, Neil Mitchell <ndmitchell(a)gmail.com> wrote: > darcs get http://darcs.haskell.org/packages/Cabal --partial > cd Cabal > runhaskell Setup configure > > And I get the error: > > ./Distribution/Simple.hs:61:1: lexical error > > Should this work? If not, what should I be doing. If Distribution directory is in the same directory, runhaskell find and use that. So, Setup.(l)hs import Distribution directory's source file, not ghc's Distribution/*. And ./Distribution/Simple.hs uses C preprocessor, so that cause lexical error. If you want to solve this error, you should use cpp option like this. runhaskell -cpp Setup.lhs configure runhaskell -cpp Setup.lhs build runhaskell -cpp Setup.lhs install Or you have to change to add below pragma per file that you can see lexical error. {-# OPTIONS -cpp #-} -- shelarcy <shelarcy capella.freemail.ne.jp> http://page.freett.com/shelarcy/

2 1

Re: [Haskell-cafe] cabal specify a "tested version", ghci target?
by Duncan Coutts 20 Aug '06

20 Aug '06

On Sat, 2006-08-12 at 03:52 +0200, Marc Weber wrote: > 1.) > I know I can use > Build-Depends: lib == <version>, lib2 < version, lib3 >= version > and so on. > > Do you think it would be useful to introducue some notation to indicate > a "tested with" ? > > Reason, purpose: I think its sometimes the case that a author/ mantainer > is quite busy with other projects and misses that some dependencies > break things.. If you want to try out you're left with some compiler > errors and a dependency and have to try out which version works. > > I would propose using this syntax: > lib-1.3 >=1.1 > to indicate that lib 1.1 is required at leeast and tested with up to > 1.3.. Cabal might then give a warning if you try to use 1.4 or greater > "using newer version than tested" or similar.. > > What do you think? > Would this be useful? Well there is actually already a "tested-with:" field that you can put in a .cabal file, however at the moment it refers only to the Haskell implementation, eg ghc-x.y, hugs-x.y etc not to versions of libraries. Yes, I think it's a quite reasonable argument to extend this to include exact versions of libraries that it has been tested with. What do others think? Duncan

2 1

expanding use of the Program abstraction
by Isaac Jones 20 Aug '06

20 Aug '06

I wonder if someone is interested in expanding the use of Program inside Cabal. There's a type in cabal Distribution.Program.Program which does some nice stuff for describing programs internally for Cabal. A program is basically a name, a location, and some arguments: -- |Represents a program which cabal may call. data Program = Program { -- |The simple name of the program, eg ghc programName :: String -- |The name of this program's binary, eg ghc-6.4 ,programBinName :: String -- |Default command-line args for this program ,programArgs :: [String] -- |Location of the program. eg. \/usr\/bin\/ghc-6.4 ,programLocation :: ProgramLocation } deriving (Read, Show) One nice thing about using it is that any program that is registered with Cabal will get some "configure" and ".cabal" helpers like --with-foo-args --foo-path= and extra-foo-args: There's also good default behavior for trying to find "foo" in PATH, being able to override its location, etc. There's also a hook for adding programs in a Setup.lhs script so that you get these flags and such so that you don't have to write all the PATH logic inside Setup.lhs. The only thing that's wrong w/ Program is that its not used all over Cabal :) Tools like ranlib do use it, I think, but not all preprocessors and the compilers don't use it. Does anyone feel like digging around in Cabal and expanding the use of Program so that we have more consistent flags and such? Some basic TODOs are here: http://hackage.haskell.org/trac/hackage/search?q=Distribution.Program&ticke… peace, isaac

1 0