From ndmitchell at gmail.com  Mon Jan  1 12:19:47 2007
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Mon Jan  1 12:16:19 2007
Subject: [David Waern] Re: darcs patch: Add preliminary support for
	haddock-ghc
In-Reply-To: <33062.193.11.241.252.1167575489.squirrel@webmail.chalmers.se>
References: <83bqlkkhhv.fsf@bishop.syntaxpolice.org>
	<404396ef0612301704i4896faf1geb801ac838e2cfd7@mail.gmail.com>
	<33062.193.11.241.252.1167575489.squirrel@webmail.chalmers.se>
Message-ID: <404396ef0701010919k2bb95cads725fc5139fa941a5@mail.gmail.com>

Hi,

> No, it doesn't work yet. So I turn the question around: Will GADT's and
> other extensions be supported by Hoogle in the future?

To some degree, yes. A GADT will probably be recorded as though it was
a normal ADT for type matching purposes. It's similar with forall at
the moment, they are entirely dropped for type matching purposes, but
are searched.

> Without such
> support, how useful would it be to include Hoogle support in haddock-ghc?

I would have thought quite useful, for example if you are going to
hoogle something like Yampa, you'll need something which can at least
ignore the GADT's.

My larger concern was if haddock-ghc is going to replace haddock one
day, then I'll definately want --hoogle in there.

Thanks

Neil
From ross at soi.city.ac.uk  Thu Jan  4 10:15:41 2007
From: ross at soi.city.ac.uk (Ross Paterson)
Date: Thu Jan  4 10:12:17 2007
Subject: new Darcs-Repository field?
Message-ID: <20070104151541.GA16260@soi.city.ac.uk>

Bj?rn Bringert suggested that the Hackage page for a package should
include a link to the Darcs repo (if any, but who uses anything else?)
and maybe some darcs integration such as changelogs and the like.
To make this work, we'd need a URL-valued Darcs-Repository field in the
package description.

From davve at dtek.chalmers.se  Thu Jan  4 20:58:20 2007
From: davve at dtek.chalmers.se (davve@dtek.chalmers.se)
Date: Thu Jan  4 20:54:43 2007
Subject: darcs patch: Add preliminary support for haddock-ghc (and 2 more)
Message-ID: <20070105015820.085BE45C1@anubis.medic.chalmers.se>

Fri Sep 15 21:29:49 CEST 2006  davve@dtek.chalmers.se
  * Add preliminary support for haddock-ghc

Fri Dec 29 20:54:39 CET 2006  davve@dtek.chalmers.se
  * Make sure haddock-ghc really creates the output dir

Sun Dec 31 00:21:16 CET 2006  davve@dtek.chalmers.se
  * Add compilerPath to Paths_<pkg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 11224 bytes
Desc: A darcs patch for your repository!
Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070105/4f02f59f/attachment.bin
From ijones at syntaxpolice.org  Fri Jan  5 13:43:16 2007
From: ijones at syntaxpolice.org (Isaac Jones)
Date: Fri Jan  5 14:08:32 2007
Subject: new Darcs-Repository field?
In-Reply-To: <20070104151541.GA16260@soi.city.ac.uk> (Ross Paterson's message
	of "Thu, 4 Jan 2007 15:15:41 +0000")
References: <20070104151541.GA16260@soi.city.ac.uk>
Message-ID: <83r6u9xqkb.fsf@bishop.syntaxpolice.org>

Ross Paterson <ross@soi.city.ac.uk> writes:

> Bj?rn Bringert suggested that the Hackage page for a package should
> include a link to the Darcs repo (if any, but who uses anything else?)
> and maybe some darcs integration such as changelogs and the like.
> To make this work, we'd need a URL-valued Darcs-Repository field in the
> package description.

I'm all for it.  I'd love tighter integration with darcs.  FYI, I
think that's what some people use the package-url for.

We could also do a "pull" for such packages and host a version of the
repo on hackage.  If there's no darcs-repository, we could just create
one so we'd have a local version.

It would be great if Hackage could some day become the "public" repo
for many darcs projects, without having to give folks login accounts.

I picture a place where people can send patches
(packagename@hackage.haskell.org), and the owner(s) of the repo would
have a UI for browsing and accepting / applying patches.  Signed
packages by approved folks would get applied automatically.

Cabal-install could have a --get-repo option, so when the user fetches
the source, they get a darcs repository.

In Debian, the maintainers are distinct from the upstream developers,
and the same might be true in Hackage.  Debian uses tarred patches to
maintain the differences between the trees, but we could use darcs.

If a package sits unmaintained for a while... maybe the upstream
author has stopped applying patches, then people could volunteer to
take over the package or fork it.

To some extent these are juts darcs user interface ideas, but I think
that the combination of a version control system and a package manager
has a lot of possibilities.

So many possibilities :)

peace,

  isaac
From davve at dtek.chalmers.se  Fri Jan  5 16:28:02 2007
From: davve at dtek.chalmers.se (davve@dtek.chalmers.se)
Date: Fri Jan  5 16:24:23 2007
Subject: darcs patch: Add preliminary support for haddock-ghc (and 1 more)
Message-ID: <20070105212802.E98118CA7@anubis.medic.chalmers.se>

Fri Sep 15 21:29:49 CEST 2006  davve@dtek.chalmers.se
  * Add preliminary support for haddock-ghc

Fri Jan  5 22:22:24 CET 2007  davve@dtek.chalmers.se
  * Add -D__HADDOCK__ to haddock-ghc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 10927 bytes
Desc: A darcs patch for your repository!
Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070105/526da8da/attachment-0001.bin
From davve at dtek.chalmers.se  Fri Jan  5 16:38:13 2007
From: davve at dtek.chalmers.se (David Waern)
Date: Fri Jan  5 16:34:33 2007
Subject: darcs patch: Add preliminary support for haddock-ghc (and 1
	more)
In-Reply-To: <20070105212802.E98118CA7@anubis.medic.chalmers.se>
References: <20070105212802.E98118CA7@anubis.medic.chalmers.se>
Message-ID: <86EFF37E-98D2-4EFD-AB68-C26B2F8AFC9F@dtek.chalmers.se>

Erhm.. please ignore the first one of these patches, since I've  
already sent it in. Seems like darcs send is a bit buggy.

/David

5 jan 2007 kl. 22.28 skrev davve@dtek.chalmers.se:

> Fri Sep 15 21:29:49 CEST 2006  davve@dtek.chalmers.se
>   * Add preliminary support for haddock-ghc
>
> Fri Jan  5 22:22:24 CET 2007  davve@dtek.chalmers.se
>   * Add -D__HADDOCK__ to haddock-ghc
>
> New patches:
>
> [Add preliminary support for haddock-ghc
> davve@dtek.chalmers.se**20060915192949] {
> hunk ./Distribution/Program.hs 57
> +                           , haddockGHCProgram
> hunk ./Distribution/Program.hs 108
> +                              , haddockGHCProgram
> hunk ./Distribution/Program.hs 188
> +haddockGHCProgram :: Program
> +haddockGHCProgram = simpleProgram "haddock-ghc"
> +
> hunk ./Distribution/Setup.hs 92
> +            | HaddockGHCCmd           -- haddock-ghc
> hunk ./Distribution/Setup.hs 364
> -                        copyCmd, sdistCmd, testCmd, haddockCmd,  
> programaticaCmd,
> -                        registerCmd, unregisterCmd]
> +                        copyCmd, sdistCmd, testCmd, haddockCmd,  
> haddockGHCCmd,
> +                        programaticaCmd, registerCmd, unregisterCmd]
> hunk ./Distribution/Setup.hs 577
> +
> +haddockGHCCmd :: Cmd a
> +haddockGHCCmd = Cmd {
> +        cmdName        = "haddock-ghc",
> +        cmdHelp        = "Generate Haddock HTML code from Exposed- 
> Modules, using haddock-ghc.",
> +        cmdDescription = "Requires haddock-ghc.",
> +        cmdOptions     = [cmd_help, cmd_verbose,
> +                          Option "" ["hoogle"] (NoArg  
> HaddockHoogle) "Generate a hoogle database"],
> +        cmdAction      = HaddockGHCCmd
> +        }
> hunk ./Distribution/Simple/GHC.hs 47
> -	build, installLib, installExe
> +	build, installLib, installExe, constructGeneralGHCCmdLine
> hunk ./Distribution/Simple/GHC.hs 339
> -
> -constructGHCCmdLine
> -	:: LocalBuildInfo
> +constructGeneralGHCCmdLine :: LocalBuildInfo
> hunk ./Distribution/Simple/GHC.hs 342
> -	-> Int				-- verbosity level
> hunk ./Distribution/Simple/GHC.hs 343
> -constructGHCCmdLine lbi bi odir verbose =
> -        ["--make"]
> -     ++ (if verbose > 4 then ["-v"] else [])
> -	    -- Unsupported extensions have already been checked by configure
> -     ++ (if compilerVersion (compiler lbi) > Version [6,4] []
> -            then ["-hide-all-packages"]
> -            else [])
> +constructGeneralGHCCmdLine lbi bi odir =
> +    (if compilerVersion (compiler lbi) > Version [6,4] []
> +         then ["-hide-all-packages"]
> +         else [])
> hunk ./Distribution/Simple/GHC.hs 358
> +constructGHCCmdLine
> +	:: LocalBuildInfo
> +        -> BuildInfo
> +	-> FilePath
> +	-> Int				-- verbosity level
> +        -> [String]
> +constructGHCCmdLine lbi bi odir verbose =
> +        ["--make"]
> +     ++ (if verbose > 4 then ["-v"] else [])
> +     ++ constructGeneralGHCCmdLine lbi bi odir
> +
> hunk ./Distribution/Simple.hs 72
> -                            haddockProgram, rawSystemProgram,  
> defaultProgramConfiguration,
> -                            pfesetupProgram, updateProgram,   
> rawSystemProgramConf)
> +                            haddockProgram, haddockGHCProgram,  
> rawSystemProgram,
> +                            defaultProgramConfiguration,  
> pfesetupProgram, updateProgram,
> +                            rawSystemProgramConf)
> hunk ./Distribution/Simple.hs 98
> +import Distribution.Simple.GHC ( constructGeneralGHCCmdLine )
> +
> hunk ./Distribution/Simple.hs 209
> +      -- |Hook to run before haddock command.  Second arg  
> indicates verbosity level.
> +     preGHCHaddock  :: Args -> HaddockFlags -> IO HookedBuildInfo,
> +      -- |Hook to run after haddock command.  Second arg indicates  
> verbosity level.
> +      -- |Over-ride this hook to get different behavior during  
> haddock.
> +     haddockGHCHook :: PackageDescription -> LocalBuildInfo ->  
> Maybe UserHooks -> HaddockFlags -> IO (),
> +     postGHCHaddock :: Args -> HaddockFlags -> PackageDescription - 
> > LocalBuildInfo -> IO ExitCode,
> +
> hunk ./Distribution/Simple.hs 316
> +            HaddockGHCCmd -> do
> +                (verbose, _, args) <- parseHaddockArgs  
> emptyHaddockFlags args []
> +                pkg_descr <- hookOrInArgs preGHCHaddock args verbose
> +                localbuildinfo <- getPersistBuildConfig
> +
> +                cmdHook haddockGHCHook pkg_descr localbuildinfo  
> verbose
> +                postHook postGHCHaddock args verbose pkg_descr  
> localbuildinfo
> +
> hunk ./Distribution/Simple.hs 418
> +haddockGHC :: PackageDescription -> LocalBuildInfo -> Maybe UserHooks
> +              -> HaddockFlags -> IO ()
> +haddockGHC pkg_descr lbi hooks (HaddockFlags hoogle verbose) = do
> +    confHaddock <- do
> +        let programConf = withPrograms lbi
> +        let haddockGHCName = programName haddockGHCProgram
> +        mHaddock <- lookupProgram haddockGHCName programConf
> +        maybe (die "haddock-ghc command not found") return mHaddock
> +
> +    let tmpDir = joinPaths (buildDir lbi) "tmp"
> +    createDirectoryIfMissing True tmpDir
> +
> +    setupMessage "Running Haddock for" pkg_descr
> +
> +    let showPkg = showPackageId (package pkg_descr)
> +    let outputFlag = if hoogle then "--hoogle" else "--html"
> +
> +    withLib pkg_descr () $ \lib -> do
> +        let bi = libBuildInfo lib
> +        inFiles <- getModulePaths bi (exposedModules lib ++  
> otherModules bi)
> +        let prologName = showPkg ++ "-haddock-prolog.txt"
> +        writeFile prologName (description pkg_descr ++ "\n")
> +
> +        rawSystemProgram verbose confHaddock
> +                (["--ghc-flags",
> +                  outputFlag,
> +                  "--odir=" ++ haddockPref,
> +                  "--title=" ++ showPkg ++ ": " ++ synopsis  
> pkg_descr,
> +                  "--prologue=" ++ prologName]
> +                 ++ programArgs confHaddock
> +                 ++ (if verbose > 4 then ["--verbose"] else [])
> +                 ++ inFiles
> +                 ++ map ("--hide=" ++) (otherModules bi)
> +                 ++ ["-package-name", showPackageId (package  
> pkg_descr) ]
> +                 ++ constructGeneralGHCCmdLine lbi bi tmpDir
> +                )
> +        removeFile prologName
> +
> +    removeDirectoryRecursive tmpDir
> +
> hunk ./Distribution/Simple.hs 651
> -       postHaddock = res
> -      }
> +       postHaddock = res,
> +       preGHCHaddock  = rn,
> +       haddockGHCHook = ru,
> +       postGHCHaddock = res
> +       }
> hunk ./Distribution/Simple.hs 691
> +       haddockGHCHook = haddockGHC,
> }
>
> [Add -D__HADDOCK__ to haddock-ghc
> davve@dtek.chalmers.se**20070105212224] {
> hunk ./Distribution/Simple.hs 443
> +                  "-cpp",
> +                  "-D__HADDOCK__",
> }
>
> Context:
>
> [added --save-configure flag to clean. got some complaints that  
> there was no way to avoid reconfiguring after a clean.  now if you  
> use --save-configure, you should be able to.
> ijones@syntaxpolice.org**20061219152204]
> [tiny mod to License comments
> ijones@syntaxpolice.org**20061219060021]
> [improving help output
> ijones@syntaxpolice.org**20061219055849
>  As suggested by Claus Reinke in this ticket:
>  http://hackage.haskell.org/trac/hackage/ticket/105
> ]
> [fix ./Setup unregister --help, which was giving the help for register
> Simon Marlow <simonmar@microsoft.com>**20061215165000]
> [Fix the links in the user guide to the API docs
> Duncan Coutts <duncan.coutts@worc.ox.ac.uk>*-20061129131633]
> [Fix the links in the user guide to the API docs
> Duncan Coutts <duncan.coutts@worc.ox.ac.uk>**20061129131633]
> [haddock comments for SrcDist.hs
> ijones@syntaxpolice.org**20061127041303]
> [some haddock comments for LocalBuildInfo.hs
> ijones@syntaxpolice.org**20061127040916]
> [a little comment for JHC.hs
> ijones@syntaxpolice.org**20061127040026]
> [some comments for Install.hs
> ijones@syntaxpolice.org**20061127035919]
> [some comments for Hugs.hs
> ijones@syntaxpolice.org**20061127035310]
> [haddock comments for GHC and GHCPackageConig
> ijones@syntaxpolice.org**20061127034617]
> [some comments for Configure.hs
> ijones@syntaxpolice.org**20061127033157]
> [some comments for Build.hs
> ijones@syntaxpolice.org**20061127032409]
> [minor comments and cleanup for Setup.hs
> ijones@syntaxpolice.org**20061127031744]
> [some haddock explanation of preprocessors
> ijones@syntaxpolice.org**20061127031055]
> [some comments for Package.hs
> ijones@syntaxpolice.org**20061127025108]
> [haddockizing some comments from Make.hs
> ijones@syntaxpolice.org**20061127024142]
> [adding comments to Program.hs
> ijones@syntaxpolice.org**20061127022353]
> [comments for the Program module
> ijones@syntaxpolice.org**20061127002749]
> [don't return an error code just because there's no library to  
> register
> ijones@syntaxpolice.org**20061124144831]
> [Purely cosmetic; have '--<FOO>-args' use ARGS on their RHS rather  
> than PATH in usage output
> sof@galois.com**20061121195844]
> [parse executable field as a token (as documented), rather than  
> free text
> Ross Paterson <ross@soi.city.ac.uk>**20061120093400]
> [trim trailing spaces (including CRs) from all input lines
> Ross Paterson <ross@soi.city.ac.uk>**20061120092526]
> [help nhc98 find the import of programLocation
> Malcolm.Wallace@cs.york.ac.uk**20061117144001]
> [sdist: make it work on Windows platforms by simplifying 'tar'  
> invocation. Hopefully not at the cost of other plats (i.e., as-yet  
> untested there..)"
> sof@galois.com**20061117014832]
> [build: consult and use any user-provided settings for 'ld' and 'ar'
> sof@galois.com**20061117014622]
> [defaultUserHooks.sDistHook: pass in optional LBI to SrcDist.sdist
> sof@galois.com**20061117014448]
> [defaultProgramConfiguration: add 'ld' and 'tar' entries
> sof@galois.com**20061117014318]
> [revise Paths module for the Hugs target
> Ross Paterson <ross@soi.city.ac.uk>**20061108223349
>
>  When targetting Hugs, the Paths module now uses prefix-independent
>  paths relative to the location of the Main module of the program,
>  on all platforms.
>
>  For the Hugs target, this replaces the code using  
> GetModuleFileNameA(),
>  which never worked.  Behaviour under GHC should be unchanged.
> ]
> [Hugs: fix location of installed package info
> Ross Paterson <ross@soi.city.ac.uk>**20061021144613]
> [Fix escaping of ' chars in register.sh script.
> Duncan Coutts <duncan.coutts@worc.ox.ac.uk>**20061016215459]
> [Tidy up command comments
> Duncan Coutts <duncan.coutts@worc.ox.ac.uk>**20061013211158]
> [Fix getDataDir etc. when bindir=$prefix
> Simon Marlow <simonmar@microsoft.com>**20061013100941]
> [Update text on the front page: packages can now overlap in GHC 6.6
> Simon Marlow <simonmar@microsoft.com>**20061012114601
>
> ]
> [New unlit code "ported" from cpphs-1.2
> Lennart Kolmodin <kolmodin@dtek.chalmers.se>**20061009192609]
> [Share one more place where the cabal version is defined.
> Duncan Coutts <duncan.coutts@worc.ox.ac.uk>**20061010140027]
> [Fix spelling error in error message.
> Duncan Coutts <duncan.coutts@worc.ox.ac.uk>**20061010140013]
> [Centeralise the places that know that Cabal version number
> Duncan Coutts <duncan.coutts@worc.ox.ac.uk>**20061010135918]
> [Remove spurious debug message.
> Duncan Coutts <duncan.coutts@worc.ox.ac.uk>**20061010125643]
> [Bump to next unstable development version
> Duncan Coutts <duncan.coutts@worc.ox.ac.uk>**20061010125602]
> [Make cabal know it's own version number correctly
> Duncan Coutts <duncan.coutts@worc.ox.ac.uk>**20061010130939
>  This is an unpleasent way of doing it.
>  Will have to fix once and for all in the next version.
> ]
> [TAG 1.1.6
> Duncan Coutts <duncan.coutts@worc.ox.ac.uk>**20061009123801]
> Patch bundle hash:
> 7df51d81ae0d14dd632dc23b8cbb513cc5b5746a
> _______________________________________________
> cabal-devel mailing list
> cabal-devel@haskell.org
> http://www.haskell.org/mailman/listinfo/cabal-devel

From marco-oweber at gmx.de  Sat Jan  6 06:09:57 2007
From: marco-oweber at gmx.de (Marc Weber)
Date: Sat Jan  6 05:06:10 2007
Subject: where more info? comments on previous posts
Message-ID: <20070106110957.GA13457@gmx.de>

Isaac showed me the Wiki.

But I'm missing some pages discussing how hackage and tools should look
like or pages which summarize decisions having be made on this list..
I think this missing because everything is in an early developement stage,
right?
What about adding some pages with summaries ?

topics where I like to put my comment:

1) allow more than one atom beeing build with one cabal file?

2) configuration option, dependency handling ...
	a) different compilers / external dependencies
	b) proposal: flags my point of view
	c) hidden flags -> flag properties
	d) using availible libs
	e) posix os mingw cygwin detection? [4]
	f) build-profiles
	g) adding darcs-repository field to cabal
	h) external dependencies
	

1) allow more than one atom beeing build with one cabal file?
==============================================================

"Cabal is the lowest-level tool for Haskell package management."
I'd like to here some pro-cons about wether to allow putting libraries and
executables into one cabal file:

advantages multi atom cabal file:
      * it is one "Package"
      * one description/ license/ homepage field is sufficient
      * quote :
		"Configurations proposal
		On 10/24/06, Duncan Coutts <duncan.coutts at worc.ox.ac.uk> wrote:
		>
		> On the other hand, in Gtk2Hs I know one case where we do this. We have a
		> Graphics.UI.Gtk.Cairo api module that is only included if Gtk was built
		> against Cairo. In any case it could be faked by using cpp to just not
		> export anything rather than not having the module exposed at all. So
		> it's not clear that it's worth banning. Or maybe making it slightly
		> harder is worth it so that people don't get in the habit.

		Couldn't you split this into Gtk and Gtk-Cairo packages, where the latter is
		only built if Cairo is available? 
	so it might be really useful to build more than one library using one package..

advantages single atom cabal file:
      * It does'nt make that much sense to me to allow different executables but
	only on lib. But allowing more than one lib will introduce another
	layer of abstraction as a cabal package is no longer the smallest unit.
	You need to check dependency within a cabal file and check dependencies
	not contained in cabal files
      * If you need library x you know you can find it in file x-version.cabal

2) configuration option, dependency handling ...
==============================================================
a) different compilers versions ( see profile proposal below)
	Does it make sense to have more than one compiler version installed (eg
	ghc 6.4 6.5 and 6.6 ?) If so, whose task is to handle the different
	compilers? --with-hc-pkg=path --with-compiler=path  or -wpath
	Would it make sense to have something like gcc/java-config of gentoo ?



b) proposal: flags my point of view
	I'd like to see everything as flag.
	flags I'd like to add by default:
		- version
		- way = profiling | debug | optimized | distribution
		  (user configurable ?)
		- stability (should be set by cabal readonly
		  automatically)
	  
	refering to [2] (build optimzed, profiling and debug version)
		and [3] (Duncan tells its intentional to not allow this)
	I agree. I'd like to be able to build different versions, too.
	That's why you have a packaging system that you don't have to all
	manually..
	I yet have to look up how cabal does installing both profiling and default
	lib at the same time which was mentioned somewhere.
	One way to solve this is when building a profiling version append prof
	to its name. Thus if your lib L is build with profiling option it won't
	depend on parsec but on parsec-prof and won't be called L but L-prof.
	This way you have all you want, don't you?
	Cabal would have to add -prof option and add -prof to all names..

	refering to [1]:
	Ian Lynagh: Why not permit declaration of flags insede a configuration?
	I can't see it why it should'nt be permitted

c) hidden flags -> flag properties

	quote: " flag: fps_in_base
		 dfault: available(base >= 2) "
	I like this idea (i had this tought too before reading this post)
	But I'd like to add "properties" to flags
	
	Thus what about:
		"hiden-flag: fps_in-base"
	? This should mean the user can't modify it using configuration
	options..

d) using availible libs automatically
	refering to [http://www.haskell.org/pipermail/cabal-devel/2006-October/000230.html]
	( On why 'availible' is evil)
	quote: "1. it often doesn't mean what you want
		2. it allows auto-use deps
		3. it makes life hard for distros and cabal-get
		4. it makes the install order significant"
	comment to 1.
		If you have gtk and wxwidgets and you have the option to
		use either.. Then this would be a case I think its
		convinient to use the one already installed (?)
		But I agree that it wouldn't harm to set this option
		manually. So its cleaner to drop this auto-detection.
		Thanks for opening my eyes here!
	comment to 4. 
	I agree. So what about determining library version which fits
	best independent of what can be found on the system, but add
	semething like emerge -p or emerge -va which tells you that
	lib xy is already installed having another version ?

	Thus if you have LibA-1.0 and wont to install LibB which would
	install LibA-2.0 on a plain new system I'd like to see
	
	dependencies to be installed:
		- LibA-2.0 (you already have 1.0, use -force-LibA-1.0 to
		  use it)
		- ...
	This way installation order is not significant by default..

	I've also read about binary packagers which don't like default
	flag values.. The same could be done here. Just print the
	automatically choosen flags and prompt for confirmation like
	this

	./cabal-install LibA
		automacially determined dependencies:
		- LibB-2.0
			unstable ( set by script, readonly)
			debug ( set by script, modifiable )
		- haskell-db-2.0 (dependency of LibB)
			experimental ( set by script, readonly )
			with-postgres : no
			with-mysql (set by command-line)
			with-Flat-DB (set by default)
			with-oracle : no
		- HSQL (dependency of haskell-db)
			with-postgres ( set by target haskell-db )
			with-mysql (set by target haskell-db )

	and optionally add configure option --no-defaults
	which prevents setting flags to default values
	Then everybody would be glad, right?
	

e) posix os mingw cygwin detection? [4]

	Should os=windows be cygwin or mingw?
	no as os means operating system. mingw cygwin is no os but a build
	environment.
	I want to say it would be better to add another additional flag
	hasposix or is-mingw-build than changing os=windows to mingw/cygwin ..

f) build-profiles
	
	What about build profiles?
	a build profile would consist of eg
		- compiler-flavour
		- compiler-version
		- flags (profile, debug, ..)
		- tools (use cpp = use c2hs = use greencard = ...)

g) adding darcs-repository field to cabal

	If we talk about adding a darcs repo line to the cabal file it seems to me that
	cabal gets closer to maven which is a package management tool for java which handles
	 * repositories
	 * compilation
	 * documentation
	 * ide - integration (eclipse)
	 * packaging
	 * ..
	But there is one difference to cabal:
	It's sufficient to get the maven project description file if it contains
	information about how to get the source ..

	Thus: Does it make sense to distribute the cabal files with the source files?

	Why not add a general
	source-location: http://xy.z/.../source-2.3.tar.gz
	or 
	source-location: darcs http://...
	line and the command
	./setup fetch?
	but .. aeh this is the task of cabal-install, right?

	Sorry for this confusion.. I just don't understand yet why there are so many
	different tools and which task should be done by which tool..

h) external dependencies

	Some packages need foreign libraries (eg jnii Haskell-Java
	interface), (gtk/ wxwidgets)
	
	How to add them ???

	i don't like to install some dependencies to notice that I also
	need C-lib xy ..


	Would it make sense to add support to install non-haskell libraries such
	as wxwidgets or sqlite as well ? Thus what about writing the system a little
	bit more general to also add a build profile for C-libraries?


Unfortunately I've never used perl or CPAN.. ;(
Does a page exist describing which features to implement form cpan?
EG centralization ? CPAN seems to be mirrored and distributed all over the world.
(But I might be wrong)


Marc - sorry for this long mail

quotes

[1]  -------------------------------------
	Ian Lynagh igloo at earth.li
	Tue Oct 31 20:13:02 EST 2006

	    * Previous message: Configurations proposal
	    * Next message: Configurations proposal
	    * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]


	----- Other bits

	A couple of other things occured to me. First, it should not be
	permitted to declare flags inside a configuration (I don't think anyone
	was saying otherwise, but I also don't think I saw it explicitly
	stated).


[2]  -------------------------------------

Configurations proposal
Brian Smith brianlsmith at gmail.com
Wed Oct 25 10:39:23 EDT 2006

On 10/24/06, Duncan Coutts <duncan.coutts at worc.ox.ac.uk> wrote:
>
> Hi All,
>
> Before the 6.6 release we had a longish discussion on how to do
> configurations and their semantics and implementation complexity etc.
>
> I would like to re-propose the last scheme that I cam up with. I'll try
> to make it a concrete proposal as well as giving some motivating
> examples to give the intuition of the meaning.


The only way I have really wanted to use configurations so far is to build
debug, profiling, and optimized versions of a library. In order to build
multiple configurations, is it going to still be the case that I have to
"configure / build / install" separately for each configuration? I would
like to be able to say something like "Setup.lhs configure --optimized
--debug --profiled" to build all three versions at once.


[3]  ------------------------------------------

Duncan Coutts duncan.coutts at worc.ox.ac.uk
Wed Oct 25 13:56:24 EDT 2006

    * Previous message: Configurations proposal
    * Next message: Configurations proposal
    * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

> How can I say that I want the DEBUG version of package "bar" to depend
> on the DEBUG version of package "foo."?  Is this allowed? 

No. This is not allowed. Indeed you can't express it with the syntax.
That's because we don't record which configurations were active for a
package that was built. This is intentional.

[4]
Brian Smith brianlsmith at gmail.com
Thu Oct 26 11:52:48 EDT 2006

    * Previous message: Configurations proposal
    * Next message: Configurations proposal
    * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

[...]
I agree--I wish System.Info.os worked differently, actually. But, there are
apparently some people (not me) that use Haskell on Cygwin, and they need to
be able to detect it, because e.g. Posix and Readline are available on
Cygwin but not Mingw. Maybe os(x) should be either "mingw" or "cygwin"?

- Brian


[4]  ----------------------------------

Configurations proposal
Duncan Coutts duncan.coutts at worc.ox.ac.uk
Tue Oct 31 20:34:35 EST 2006

>     flag: fps_in_base
>     default: available(base >= 2)
> 
>     configuration: fps_in_base
>     build-depends: base(>= 2)
> 
>     configuration: !fps_in_base
>     build-depends: base(< 2), fps
> 
> The user would be able to shoot themselves in the foot by overidding the
> fps_in_base flag such that they don't have the deps installed, but
> that's their own fault. Note that the right thing will happen if they
> just leave it as the default.

Yeah it'd work but I don't like it.

It exposes too much to the user for one thing. It's not always going to
do the the right thing either. In this case you can only have one
version of base installed at once, but for other libs that's not the
case. So imagine I do have base-1.0 and 2.0 installed then there's no
From marco-oweber at gmx.de  Sat Jan  6 06:38:43 2007
From: marco-oweber at gmx.de (Marc Weber)
Date: Sat Jan  6 05:34:56 2007
Subject: security/ experimental packages? authorization uncomon source
	locations, hackage db?
Message-ID: <20070106113843.GA21452@gmx.de>

I've read the discussion about who is able to upload packages..
This is nice if you want to install most common packages..

But the packaging system is intended to save time. Thus what about
I want to install an experimntal synthesizer which uses an experimental
haskore interface from a person who hasn't registered his lib on
hackage-db yet?

In short:
Would it be useful to allow speciyfing different download locations for
dependencies in a cabal file?

-- Lib.cabal --
depends: ExperimentalLib > 2.0  { location: http://person/haskell/ExperimentalLib.cabal }
[...]

This would give much more freedom ..

I agree that it might be useful to "mask" those packages ...
But its much more convinient to do

cabal-install --allow-non-hackage-locations Lib

than downloading/ installing/ updating those libs manually ?

I think if you need total security you won't use this flag or use
someithing like chroot (already mentioned) or user mode linux .. ;)

But this issue adresses the question:
What is hackage about:
	an automated installation system
or
	an automated installation system + package list (centralized at
	hackagedb ?)

Marc
From marco-oweber at gmx.de  Sat Jan  6 07:05:22 2007
From: marco-oweber at gmx.de (Marc Weber)
Date: Sat Jan  6 06:01:35 2007
Subject: debugging support - multidimensional package selection - excursion
Message-ID: <20070106120522.GB21452@gmx.de>

If we want to add debugging support consider a packagetree like this:

a - b ( depends on b and c, c on d and e)
|
+ - c - d
    |
    + - e
 

its obvious if I want to have a profiling lib a I need b..e compiled
with -prof, too

But if I want to build it with debugging messages what about b,c,d,e 
They might have been compiled with debugging support but don't have to.

Consider the scenario a,c,d beeing compiled as debugging, but I'm also
working on another project which doesn't need c as debugging.

This would mean I need two versions of c (with debugging enabled and
disabled) -> naming conflict..

This could be solved by introducing aliases.

eg 

./cabal-install d as d-debug --enable-debug
./cabal-install c as c-debug --enable-debug --with d-debug as d
./cabal-install a  --with c-debug as c

and I would be done

This way you can even install different developement versions of your
libraries .. (sure testing should be done with HUnit or qpuickcheck not
with final applications ..)

Of course this is only useful for testing not for distribution ...

I don't think this would make things much more complicated but would
make the system much more flexible ..


Wait.. This would mean:
you have a package id and you have flags to select the right version
	a flag is a) version
	          b) configure options such as profile, debug, use lib a
		  instead of b, ...

But this would mean when deciding which libraries to install by default:
instance Default Stability  -- stable wins
instance Default Version  -- greater wins
instance Default Debug -- no debug wins
instance Default Profiling -- no profiling wins
if not specified else.

This leads me to the question: Is it enough to identify a package by
(name/id) and version?

I think a more dimensional way would be useful

Thus adding another dimension (os / 
instance Default Cross-Compilation-Target -- defaults to no cross-compilation
an easy extension..

And this would make it easy to manage libs for your os, that of your
neighbour, your microcontroller, ....

Of course ghc-pkg list will no longer show
Lib (version=2.0, debug=on, profiling=on, target-architecture=x64)
rather than
Lib-2.0

Some of those flags would be backtracking (architecture, profiling)
others not (debug = on)

Fortunately you don't have the design of ghc to test this as you can use
aliases ..

Any comments? Is this all nonsense ?

Marc
From duncan.coutts at worc.ox.ac.uk  Sun Jan  7 16:30:49 2007
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Sun Jan  7 17:21:48 2007
Subject: new Darcs-Repository field?
In-Reply-To: <20070104151541.GA16260@soi.city.ac.uk>
References: <20070104151541.GA16260@soi.city.ac.uk>
Message-ID: <1168205450.19455.114.camel@localhost>

On Thu, 2007-01-04 at 15:15 +0000, Ross Paterson wrote:
> Bj?rn Bringert suggested that the Hackage page for a package should
> include a link to the Darcs repo (if any, but who uses anything else?)
> and maybe some darcs integration such as changelogs and the like.
> To make this work, we'd need a URL-valued Darcs-Repository field in the
> package description.

I think this is a good idea.

Can we get away with only allowing darcs? :-)

Here's what gentoo has for its global overlay configuration file (a
gentoo overlay is a tree of ebuild files usually managed in a version
control system):

  <overlay
      type = "svn"
      src  = "https://gentooscience.org/svn/overlay"
      contact = "sci@gentoo.org"
      status  = "official"
      name = "science">

  <overlay
      type = "rsync"
      src  = "rsync://rsync.breakmygentoo.net/bmg-main/bmg-main"
      contact = "bugs.breakmygentoo.net"
      name = "break-my-gentoo-main">

  <overlay
      type = "darcs"
      src  = "http://www.haskell.org/~gentoo/gentoo-haskell/"
      contact = "haskell@gentoo.org"
      status = "official"
      name = "haskell">

  <overlay
      type = "tar"
      src  = "http://geki.ath.cx/OOo/openoffice.tar.bz2"
      contact = "h.mth@web.de"
      name = "openoffice-geki">

etc, you get the idea. So they have a 'type' field as well as a url for
it. We could do the same and for the moment only implement stuff for
darcs.

How about:

rcs-type:
rcs-url:

Hmm ok, not so good. Someone come up with something less cryptic :-)

Duncan

From ndmitchell at gmail.com  Sun Jan  7 17:28:37 2007
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Sun Jan  7 17:24:49 2007
Subject: new Darcs-Repository field?
In-Reply-To: <1168205450.19455.114.camel@localhost>
References: <20070104151541.GA16260@soi.city.ac.uk>
	<1168205450.19455.114.camel@localhost>
Message-ID: <404396ef0701071428i14ebc40dq8058c22e7fc403cb@mail.gmail.com>

Hi

> Can we get away with only allowing darcs? :-)

If we only allow darcs, that will persuade more Haskell developers to
migrate to darcs, and will simplify the life for Haskell users. If
there was a free hosting place which offered darcs repo's then the
answer is probably yes.

Yhc depends on one svn repo, and its annoying to introduce an
additional dependancy.

Thanks

Neil
From ijones at syntaxpolice.org  Tue Jan  9 17:23:08 2007
From: ijones at syntaxpolice.org (Isaac Jones)
Date: Tue Jan  9 17:19:27 2007
Subject: hackage projects for Hackathon
Message-ID: <83d55net6b.fsf@bishop.syntaxpolice.org>

Greetings!  Many of you will be at the Hackathon tomorrow:
http://www.haskell.org/haskellwiki/Hac_2007

I just did a brain-dump of what I think needs to get done to make
cabal-install and hackage a reality.  Much of the Hacking is already
done and in good shape, but there are probably lots of little things
to do, and there is work that needs to happen in order to gain
adoption from the community.

Here's my brain dump:
http://hackage.haskell.org/trac/hackage/ticket/107

Of course, I'm not the only one with ideas, and others might have a
lot of good ideas about what needs to be done.  Above all, make it
yours!

Linked from the Hac 07 project page:
http://www.haskell.org/haskellwiki/Hac_2007/Projects

I'm going to try to be on IRC for some of the event, although the time
of day isn't the best for me (since it starts at 2AM my time) :)

peace,

  isaac
From marco-oweber at gmx.de  Tue Jan  9 21:25:30 2007
From: marco-oweber at gmx.de (Marc Weber)
Date: Tue Jan  9 20:21:42 2007
Subject: Why is there a cabal file at all?
Message-ID: <20070110022530.GB29286@gmx.de>

Sorry for this stupid question put there must be reasons I don't know.

I've been thinking a lot about packaging/ dependency handling etc the
last days.

Haskell is one of the most typesafe and expressive languages, right?

Now we need a haskell compiler/ interpreter to run Setup.hs.

So why not combine both and use some kind of cabal combinator library?

I'll try to implement a prototype although knowing there are lots of
people knowing how to do this better.


module Setup where
import CabalBuildProposal

helloWorld = haskell-executable $ do
  setName "helloworld"
  sourceDir "src" $ mainIs "HelloWorld.hs"
  addDependencies = case stringOption "pretty_print_lib" of
    "A" : [LibVersionRange "A" "1.0 - 2.0"]
    "B" : [LibVersionRange "B" "1.0 - 2.0"]

package = do
  setAuthor = "Marc Weber"
  addAtom helloWorld

preprocess = defaultHaskellPreprocess
build = preprocess >>= defaultHaskellBuild
rpm = build >>= defaultRPM
install = defaultHaskellInstall
haddock = defaultHaddock

targets = [ ("preprocessOnly", preprocess)
	  , ("build", build )
	  , ("install", build >>= install) 
	  , ("rpm", rpm ) 
	  , ("haddock", preprocess >>= haddock)
	  ]

main = do
  handle package targets

using preprocessors might be done in this way:

addExposedModules $ map preprocessByCPP $ modulesByRegex "src/**/*.hs"


I think you get the idea why this approach might be much more powerful?
The package mantainers of ght2hs and wkhaskell have both trouble makeing their
project work with cabal..
So why do we limit ourself using cabal files like the existing ones?

I think you've noticed the line 
	addDependencies = case stringOption "pretty_print_lib" of

This should use the correct dependency if the option has already been set by
cmdline or config file else ask the user or choose the first but noticing the
user by printing a message like this:

	unset option "pretty_print_lib", defaulting to "A"

preprocess should be passed all configuration options and return a list of source files,
build should get the list of source file and return a list of executables
which are installed by install

straightforward, isn't it?

Thus the right build/ install whatsoever step would be choosen not by defining
hooks but by the haskell type system.
This way the packaging system user can plug in his own implementation
everywhere.

Any ideas, comments?

Anyone out there who wants to join and help implementing this idea?

Marc
From ndmitchell at gmail.com  Tue Jan  9 20:39:08 2007
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Tue Jan  9 20:35:12 2007
Subject: Why is there a cabal file at all?
In-Reply-To: <20070110022530.GB29286@gmx.de>
References: <20070110022530.GB29286@gmx.de>
Message-ID: <404396ef0701091739t35c47d44tc362003195534d9b@mail.gmail.com>

Hi Marc,

[Snip]

> Any ideas, comments?
>
> Anyone out there who wants to join and help implementing this idea?

I'd ask why there is a Setup.hs file at all, a nice textual
declarative form seems much more sensible. You can encode everything
in Haskell, but you probably shouldn't...

First off, its harder to read, harder to parse (unless you happen to
be a Haskell compiler) and just not as straight forward. Should you be
able to pick which library version you want based on the day of the
week? Should your package name be allowed to be a random string which
changes each time?

It is a cute idea (less different forms), but I don't think it fits
the problem in this case.

Thanks

Neil
From conal at conal.net  Tue Jan  9 22:41:57 2007
From: conal at conal.net (Conal Elliott)
Date: Tue Jan  9 22:38:02 2007
Subject: Why is there a cabal file at all?
In-Reply-To: <404396ef0701091739t35c47d44tc362003195534d9b@mail.gmail.com>
References: <20070110022530.GB29286@gmx.de>
	<404396ef0701091739t35c47d44tc362003195534d9b@mail.gmail.com>
Message-ID: <ea8ae9fb0701091941n85dc83fk82431675d357ff02@mail.gmail.com>

Marc points out that the expressiveness of the Cabal language is
insufficient for some packages, and a DSEL would be more expressive.  I have
the same problem and still have to resort to makefiles to augment my .cabal
files.

DSELs also provide sharing/reuse.  I know my Cabal specs are similar, and
yet I cannot capture that commonality.

Using a DSEL does not imply that it route through IO, though from Marc's
examples I'm guessing he has IO in mind.  Avoiding IO would address your
points about day of week and random strings.

So I hope Marc's suggestion gets some consideration.

 - Conal

On 1/9/07, Neil Mitchell <ndmitchell@gmail.com> wrote:
>
> Hi Marc,
>
> [Snip]
>
> > Any ideas, comments?
> >
> > Anyone out there who wants to join and help implementing this idea?
>
> I'd ask why there is a Setup.hs file at all, a nice textual
> declarative form seems much more sensible. You can encode everything
> in Haskell, but you probably shouldn't...
>
> First off, its harder to read, harder to parse (unless you happen to
> be a Haskell compiler) and just not as straight forward. Should you be
> able to pick which library version you want based on the day of the
> week? Should your package name be allowed to be a random string which
> changes each time?
>
> It is a cute idea (less different forms), but I don't think it fits
> the problem in this case.
>
> Thanks
>
> Neil
> _______________________________________________
> cabal-devel mailing list
> cabal-devel@haskell.org
> http://www.haskell.org/mailman/listinfo/cabal-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/cabal-devel/attachments/20070109/27bcaf13/attachment.htm
From marco-oweber at gmx.de  Wed Jan 10 05:18:04 2007
From: marco-oweber at gmx.de (Marc Weber)
Date: Wed Jan 10 04:14:19 2007
Subject: Why is there a cabal file at all?
In-Reply-To: <404396ef0701091739t35c47d44tc362003195534d9b@mail.gmail.com>
References: <20070110022530.GB29286@gmx.de>
	<404396ef0701091739t35c47d44tc362003195534d9b@mail.gmail.com>
Message-ID: <20070110101804.GC29286@gmx.de>

On Wed, Jan 10, 2007 at 01:39:08AM +0000, Neil Mitchell wrote:
> Hi Marc,
> 
> [Snip]
> 
> >Any ideas, comments?
> >
> >Anyone out there who wants to join and help implementing this idea?
> 
> I'd ask why there is a Setup.hs file at all, a nice textual
> declarative form seems much more sensible.

Thus you are asking why there is support for hooks at all?
Sorry I can't follow you, sir!

You can encode everything
> in Haskell, but you probably shouldn't...

> First off, its harder to read, harder to parse (unless you happen to
> be a Haskell compiler)
Aeh.. Why are you programming in haskell, than?
Again I can't follow..
If this is hard to parse, would you mind pointing me to the lines you
had real troubl understanding them?

Or do you think its hard to read / use for total haskell beginners?

If so its no problem to also provide a function as cabal does has it:

replace the line

	handle congfig targets
by
	handleFromSimpleTextFile
and every one will be happy?

and just not as straight forward. Should you be
> able to pick which library version you want based on the day of the
> week? 
> Should your package name be allowed to be a random string which
> changes each time?
Why not ? If somewody likes to?
But the library won't be used than..
He can do this now, too. He/ she has to provide a different cabal file each
day.. This shouldn't be any problem using php name: <?=randomString?>

How do you protect people from using libs with rubbish code?
I can't do anything moro than quote yourself:

"
I would demand at the very least a real name, email address - but
really, in an online world those things are nearly useless. I guess
the only thing to do is to trust that people who have learnt enough
about monads and IO to hijack Haskell things probably realise how cool
Haskell is...
" (quoted from
   http://www.haskell.org/pipermail/libraries/2007-January/006662.html)

I think this might apply here, too ;) If you don't unerstand how I think this
applies aske again.

But I think its not much effort convincing me to write simple text files ;)

I adbmit that I plan to use this packaging system not just for haskell, but
also for compiling microcontroller code etc.. I like Makefiles but I also hate
them.. Thus textfiles justd wouldn't be expressive enough for my needs.

Thanks
	Marc
From marco-oweber at gmx.de  Wed Jan 10 05:24:34 2007
From: marco-oweber at gmx.de (Marc Weber)
Date: Wed Jan 10 04:20:40 2007
Subject: Why is there a cabal file at all?
In-Reply-To: <ea8ae9fb0701091941n85dc83fk82431675d357ff02@mail.gmail.com>
References: <20070110022530.GB29286@gmx.de>
	<404396ef0701091739t35c47d44tc362003195534d9b@mail.gmail.com>
	<ea8ae9fb0701091941n85dc83fk82431675d357ff02@mail.gmail.com>
Message-ID: <20070110102434.GD29286@gmx.de>

On Tue, Jan 09, 2007 at 07:41:57PM -0800, Conal Elliott wrote:
>    Marc points out that the expressiveness of the Cabal language is
>    insufficient for some packages, and a DSEL would be more expressive.
Sorry, I've never heard abaut DSEL yet.
I still feel like beening a total beginner.. ;)
But I'll try to fill this lack of knowledge.
I was thinking in IO monads as I didn't know something better..

Conal : Can you help me lifting my skills and tell me in some sentences
how a build system could benefit from DSELs?

Marc
From ijones at syntaxpolice.org  Wed Jan 10 09:53:43 2007
From: ijones at syntaxpolice.org (Isaac Jones)
Date: Wed Jan 10 09:49:50 2007
Subject: Why is there a cabal file at all?
In-Reply-To: <ea8ae9fb0701091941n85dc83fk82431675d357ff02@mail.gmail.com>
	(Conal Elliott's message of "Tue, 9 Jan 2007 19:41:57 -0800")
References: <20070110022530.GB29286@gmx.de>
	<404396ef0701091739t35c47d44tc362003195534d9b@mail.gmail.com>
	<ea8ae9fb0701091941n85dc83fk82431675d357ff02@mail.gmail.com>
Message-ID: <831wm3rkzs.fsf@bishop.syntaxpolice.org>

"Conal Elliott" <conal@conal.net> writes:

> Marc points out that the expressiveness of the Cabal language is
> insufficient for some packages, and a DSEL would be more expressive.
> I have the same problem and still have to resort to makefiles to
> augment my .cabal files.

The original design of Cabal was more like Marc suggests.  There was
only the Setup file and no .cabal file, and my hope was that we'd
build an EDSL for package configurations.  Original cabal code would
probably look like:

main = defaultMain defaultPackageDescription{ name="foo"
                                            , synopsys="bar"}

etc.

Then I was hoping it would evolve to an EDSL.

But most people didn't like this design.  My argument was that if we
created a a.cabal file, eventually the design would get more and more
complex, so why not just start out with Haskell, which would give us
room to grow :) But there are also lots of advantages to having the
.cabal file.  Maybe someone can dig up the debate on the libraries
mailing list from a few years back.

Anyway, with the hooks interface, you can override just about all of
cabal's behavior (including inputting the description file) so there's
pleanty of room to experiment with something like an EDSL.
Unfortunitely your package would not be cabal-compliant without a
.cabal file.  We are moving more in the other direction... keeping all
of the information in .cabal and not requiring a Setup.lhs file.  That
seems to be easier for most people.

peace,

  isaac
From lemming at henning-thielemann.de  Wed Jan 10 10:08:09 2007
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Wed Jan 10 10:06:55 2007
Subject: Why is there a cabal file at all?
In-Reply-To: <831wm3rkzs.fsf@bishop.syntaxpolice.org>
References: <20070110022530.GB29286@gmx.de>
	<404396ef0701091739t35c47d44tc362003195534d9b@mail.gmail.com>
	<ea8ae9fb0701091941n85dc83fk82431675d357ff02@mail.gmail.com>
	<831wm3rkzs.fsf@bishop.syntaxpolice.org>
Message-ID: <Pine.LNX.4.58.0701101604430.20396@linpc23.informatik.uni-halle.de>


On Wed, 10 Jan 2007, Isaac Jones wrote:

> "Conal Elliott" <conal@conal.net> writes:
> 
> > Marc points out that the expressiveness of the Cabal language is
> > insufficient for some packages, and a DSEL would be more expressive.
> > I have the same problem and still have to resort to makefiles to
> > augment my .cabal files.
> 
> The original design of Cabal was more like Marc suggests.  There was
> only the Setup file and no .cabal file, and my hope was that we'd
> build an EDSL for package configurations.  Original cabal code would
> probably look like:
> 
> main = defaultMain defaultPackageDescription{ name="foo"
>                                             , synopsys="bar"}
> 
> etc.
> 
> Then I was hoping it would evolve to an EDSL.

I also suggested to provide installers in form of Haskell modules. Simon
Marlow responded, that this would prohibit manipulation of configuration
files (that is, the .cabal files) via GUI.
From marco-oweber at gmx.de  Wed Jan 10 12:05:44 2007
From: marco-oweber at gmx.de (Marc Weber)
Date: Wed Jan 10 11:01:48 2007
Subject: Why is there a cabal file at all?
In-Reply-To: <831wm3rkzs.fsf@bishop.syntaxpolice.org>
References: <20070110022530.GB29286@gmx.de>
	<404396ef0701091739t35c47d44tc362003195534d9b@mail.gmail.com>
	<ea8ae9fb0701091941n85dc83fk82431675d357ff02@mail.gmail.com>
	<831wm3rkzs.fsf@bishop.syntaxpolice.org>
Message-ID: <20070110170544.GA30492@gmx.de>

On Wed, Jan 10, 2007 at 06:53:43AM -0800, Isaac Jones wrote:
> The original design of Cabal was more like Marc suggests.  There was
> only the Setup file and no .cabal file, and my hope was that we'd
> build an EDSL for package configurations.  Original cabal code would
> probably look like:
> 
> main = defaultMain defaultPackageDescription{ name="foo"
>                                             , synopsys="bar"}
> complex, so why not just start out with Haskell, which would give us
> room to grow :) But there are also lots of advantages to having the
> .cabal file.  Maybe someone can dig up the debate on the libraries
> mailing list from a few years back.
 
> Anyway, with the hooks interface, you can override just about all of
> cabal's behavior 

Sure I can. But I'd like to have it the other way round with a function:
readDescription from Cabal file..

Thanks for clarifying.

Isaac: I'm new to this project cabal/ hackage. So I need to know wether
this is still the right place to discuss this (because this descission
has been made some time ago and Cabal seems to move in a direction I
don't like (using text/ cabal file like configurations)

Or is the right thing to do fork and create another mailinglist if
anyone is interested, too?

Anyway it would be cool to put these kinds of "descission" having been
made long time ago somewhere on the cabal page for information why Cabal
is the way it is.

When I come up with something useful I'll post here again.

peace, thanks, .. ;)
Marc
From lemming at henning-thielemann.de  Wed Jan 10 11:11:02 2007
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Wed Jan 10 11:08:29 2007
Subject: Why is there a cabal file at all?
In-Reply-To: <20070110170544.GA30492@gmx.de>
References: <20070110022530.GB29286@gmx.de>
	<404396ef0701091739t35c47d44tc362003195534d9b@mail.gmail.com>
	<ea8ae9fb0701091941n85dc83fk82431675d357ff02@mail.gmail.com>
	<831wm3rkzs.fsf@bishop.syntaxpolice.org>
	<20070110170544.GA30492@gmx.de>
Message-ID: <Pine.LNX.4.58.0701101707580.20396@linpc23.informatik.uni-halle.de>


On Wed, 10 Jan 2007, Marc Weber wrote:

> On Wed, Jan 10, 2007 at 06:53:43AM -0800, Isaac Jones wrote:
> > The original design of Cabal was more like Marc suggests.  There was
> > only the Setup file and no .cabal file, and my hope was that we'd
> > build an EDSL for package configurations.  Original cabal code would
> > probably look like:
> > 
> > main = defaultMain defaultPackageDescription{ name="foo"
> >                                             , synopsys="bar"}
> > complex, so why not just start out with Haskell, which would give us
> > room to grow :) But there are also lots of advantages to having the
> > .cabal file.  Maybe someone can dig up the debate on the libraries
> > mailing list from a few years back.
>  
> > Anyway, with the hooks interface, you can override just about all of
> > cabal's behavior 
> 
> Sure I can. But I'd like to have it the other way round with a function:
> readDescription from Cabal file..

Actually, you can do this. Probably the biggest part of Cabal is a Haskell
library. You can read package description or you can create a
PackageDescription manually and then call some of the Cabal routines.
From ijones at syntaxpolice.org  Wed Jan 10 11:22:56 2007
From: ijones at syntaxpolice.org (Isaac Jones)
Date: Wed Jan 10 11:19:02 2007
Subject: Why is there a cabal file at all?
In-Reply-To: <20070110170544.GA30492@gmx.de> (Marc Weber's message of "Wed, 10
	Jan 2007 18:05:44 +0100")
References: <20070110022530.GB29286@gmx.de>
	<404396ef0701091739t35c47d44tc362003195534d9b@mail.gmail.com>
	<ea8ae9fb0701091941n85dc83fk82431675d357ff02@mail.gmail.com>
	<831wm3rkzs.fsf@bishop.syntaxpolice.org>
	<20070110170544.GA30492@gmx.de>
Message-ID: <83bql6rgv3.fsf@bishop.syntaxpolice.org>

Marc Weber <marco-oweber@gmx.de> writes:

(snip)
> Isaac: I'm new to this project cabal/ hackage. So I need to know wether
> this is still the right place to discuss this (because this descission
> has been made some time ago and Cabal seems to move in a direction I
> don't like (using text/ cabal file like configurations)
>
> Or is the right thing to do fork and create another mailinglist if
> anyone is interested, too?

I certainly wouldn't encourage you to fork.  I think that the design
of cabal is quite good, and the closest to what users actually want.
I think that at this point, it's a bikeshed (and one that's already
been built (and painted)):
http://www.unixguide.net/freebsd/faq/16.19.shtml

There are more exciting and interesting things to work on now.  The
action is in cabal-install and hackage; building layered tools to get
Haskell programs into the hands of end-users.

But if you are seriously interested in the area of a domain specific
language for packages, I'd encourage you to make it something that
would work within the context of the hooks, so that people can write
nicer Setup scripts, and it should be pretty neutral to whether or not
there's a package description file.  Writing setup scripts isn't too
easy these days, and if you can come up with something to make it
better, that would be great.

Remember: Cabal isn't only the build infrastructure, it's also the
metadata format that tools like Hackage use.  If you decide to combine
data and code, you will no longer be able to manipulate the data with
another tool.

> Anyway it would be cool to put these kinds of "descission" having been
> made long time ago somewhere on the cabal page for information why Cabal
> is the way it is.

Feel free to do so on the wiki if you dig stuff up.

> When I come up with something useful I'll post here again.

Feel free!


peace,

  isaac
From marco-oweber at gmx.de  Thu Jan 11 07:50:17 2007
From: marco-oweber at gmx.de (Marc Weber)
Date: Thu Jan 11 06:46:18 2007
Subject: Yet another difficult project to package
In-Reply-To: <20070110170544.GA30492@gmx.de>
References: <20070110022530.GB29286@gmx.de>
	<404396ef0701091739t35c47d44tc362003195534d9b@mail.gmail.com>
	<ea8ae9fb0701091941n85dc83fk82431675d357ff02@mail.gmail.com>
	<831wm3rkzs.fsf@bishop.syntaxpolice.org>
	<20070110170544.GA30492@gmx.de>
Message-ID: <20070111125017.GB25673@gmx.de>

http://www.haskell.org/pipermail/glasgow-haskell-users/2007-January/011854.html

This mail posted to glasgow-haskell-users by Samuel has been forwarded to
libraries@haskell.org by
Simon Peyton Jones as well

Cheers
Marc
From conal at conal.net  Fri Jan 12 15:47:14 2007
From: conal at conal.net (Conal Elliott)
Date: Fri Jan 12 15:43:13 2007
Subject: Why is there a cabal file at all?
In-Reply-To: <83bql6rgv3.fsf@bishop.syntaxpolice.org>
References: <20070110022530.GB29286@gmx.de>
	<404396ef0701091739t35c47d44tc362003195534d9b@mail.gmail.com>
	<ea8ae9fb0701091941n85dc83fk82431675d357ff02@mail.gmail.com>
	<831wm3rkzs.fsf@bishop.syntaxpolice.org>
	<20070110170544.GA30492@gmx.de>
	<83bql6rgv3.fsf@bishop.syntaxpolice.org>
Message-ID: <ea8ae9fb0701121247p7ee82d38l315efc5daebcd21e@mail.gmail.com>

On 1/10/07, Isaac Jones <ijones@syntaxpolice.org> wrote:

> ...
> Remember: Cabal isn't only the build infrastructure, it's also the
> metadata format that tools like Hackage use. If you decide to combine data
> and code, you will no longer be able to manipulate the data with another
> tool.
>

I'm worried and confused about this conclusion. I want to address my
confusion first, and maybe the worry will be handled.

By "data" vs "code", I'm guessing you mean simple first-order values, and
mainly strings, vs everything else (especially functions). But I wonder if
instead you mean any Haskell value (including functions) vs the content of a
.hs file?

Maybe I'd have a firmer grasp of this issue if I could had in mind an
example of such a metadata-manipulating tool. Would someone please suggest
one?

   Regards, - Conal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/cabal-devel/attachments/20070112/99438efa/attachment.htm
From conal at conal.net  Fri Jan 12 16:23:37 2007
From: conal at conal.net (Conal Elliott)
Date: Fri Jan 12 16:19:35 2007
Subject: Why is there a cabal file at all?
In-Reply-To: <20070110102434.GD29286@gmx.de>
References: <20070110022530.GB29286@gmx.de>
	<404396ef0701091739t35c47d44tc362003195534d9b@mail.gmail.com>
	<ea8ae9fb0701091941n85dc83fk82431675d357ff02@mail.gmail.com>
	<20070110102434.GD29286@gmx.de>
Message-ID: <ea8ae9fb0701121323q2fe8ac4co5450cfdaee2593be@mail.gmail.com>

Hi Marc.

See Paul Hudak's position
paper<http://www.cs.yale.edu/homes/hudak-paul/hudak-dir/ACM-WS/position.html>on
DSELs, where you'll find definition, motivation & examples.  See also
Peter
Landin <http://en.wikipedia.org/wiki/Peter_J._Landin>'s "Next 700" paper.
If you have questions, please ask!

BTW, I hear both "EDSL" and "DSEL", and I don't recall which is more in
vogue and what reasons are for one or the other.  Maybe Paul or someone
could comment.

Cheers,  - Conal

On 1/10/07, Marc Weber <marco-oweber@gmx.de> wrote:
>
> On Tue, Jan 09, 2007 at 07:41:57PM -0800, Conal Elliott wrote:
> >    Marc points out that the expressiveness of the Cabal language is
> >    insufficient for some packages, and a DSEL would be more expressive.
> Sorry, I've never heard abaut DSEL yet.
> I still feel like beening a total beginner.. ;)
> But I'll try to fill this lack of knowledge.
> I was thinking in IO monads as I didn't know something better..
>
> Conal : Can you help me lifting my skills and tell me in some sentences
> how a build system could benefit from DSELs?
>
> Marc
> _______________________________________________
> cabal-devel mailing list
> cabal-devel@haskell.org
> http://www.haskell.org/mailman/listinfo/cabal-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/cabal-devel/attachments/20070112/745d26ab/attachment.htm
From marco-oweber at gmx.de  Fri Jan 12 16:32:48 2007
From: marco-oweber at gmx.de (Marc Weber)
Date: Fri Jan 12 16:32:50 2007
Subject: Why is there a cabal file at all? - DSEL
In-Reply-To: <ea8ae9fb0701121323q2fe8ac4co5450cfdaee2593be@mail.gmail.com>
References: <20070110022530.GB29286@gmx.de>
	<404396ef0701091739t35c47d44tc362003195534d9b@mail.gmail.com>
	<ea8ae9fb0701091941n85dc83fk82431675d357ff02@mail.gmail.com>
	<20070110102434.GD29286@gmx.de>
	<ea8ae9fb0701121323q2fe8ac4co5450cfdaee2593be@mail.gmail.com>
Message-ID: <20080112223646.GB7460@gmx.de>

On Fri, Jan 12, 2007 at 01:23:37PM -0800, Conal Elliott wrote:
>    Hi Marc.
>    See Paul Hudak's [1]position paper on DSELs, where you'll find
>    definition, motivation & examples.  See also [2]Peter Landin's "Next
>    700" paper.  If you have questions, please ask!
>    BTW, I hear both "EDSL" and "DSEL", and I don't recall which is more
>    in vogue and what reasons are for one or the other.  Maybe Paul or
>    someone could comment.
>    Cheers,  - Conal
Did I get it right this way?
I'm up to create a new DSEL, which is no new language feature but a
an application of the language to a particualr problem resulting in some
kind of library (Thus beeing specialized and more abstract?)

Marc
From ijones at syntaxpolice.org  Fri Jan 12 16:55:21 2007
From: ijones at syntaxpolice.org (Isaac Jones)
Date: Fri Jan 12 16:51:19 2007
Subject: Why is there a cabal file at all?
In-Reply-To: <ea8ae9fb0701121247p7ee82d38l315efc5daebcd21e@mail.gmail.com>
	(Conal Elliott's message of "Fri, 12 Jan 2007 12:47:14 -0800")
References: <20070110022530.GB29286@gmx.de>
	<404396ef0701091739t35c47d44tc362003195534d9b@mail.gmail.com>
	<ea8ae9fb0701091941n85dc83fk82431675d357ff02@mail.gmail.com>
	<831wm3rkzs.fsf@bishop.syntaxpolice.org>
	<20070110170544.GA30492@gmx.de>
	<83bql6rgv3.fsf@bishop.syntaxpolice.org>
	<ea8ae9fb0701121247p7ee82d38l315efc5daebcd21e@mail.gmail.com>
Message-ID: <83hcuvx646.fsf@bishop.syntaxpolice.org>

"Conal Elliott" <conal@conal.net> writes:

> On 1/10/07, Isaac Jones <ijones@syntaxpolice.org> wrote:
>
>> ...
>> Remember: Cabal isn't only the build infrastructure, it's also the
>> metadata format that tools like Hackage use. If you decide to combine data
>> and code, you will no longer be able to manipulate the data with another
>> tool.
>>
>
> I'm worried and confused about this conclusion. I want to address my
> confusion first, and maybe the worry will be handled.
>
> By "data" vs "code", I'm guessing you mean simple first-order values, and
> mainly strings, vs everything else (especially functions). But I wonder if
> instead you mean any Haskell value (including functions) vs the content of a
> .hs file?

I'm not sure what you mean here.  What I'm talking about is that if
you have a programatic way of producing the package description, then
you no longer have a way of "reading" that package description from
another tool.

> Maybe I'd have a firmer grasp of this issue if I could had in mind an
> example of such a metadata-manipulating tool. Would someone please suggest
> one?

Visual Haskell, HackageDB, cabal2rpm, and dh_haskell are all tools
that read the .cabal file and perform operations based on the package
metadata.  These tools would have to be Haskell interpreters if they
wanted to read a .hs file and derive the package description from
that.

peace,

  isaac
From marco-oweber at gmx.de  Fri Jan 12 23:04:29 2007
From: marco-oweber at gmx.de (Marc Weber)
Date: Fri Jan 12 23:04:30 2007
Subject: Why is there a cabal file at all?
In-Reply-To: <83hcuvx646.fsf@bishop.syntaxpolice.org>
References: <20070110022530.GB29286@gmx.de>
	<404396ef0701091739t35c47d44tc362003195534d9b@mail.gmail.com>
	<ea8ae9fb0701091941n85dc83fk82431675d357ff02@mail.gmail.com>
	<831wm3rkzs.fsf@bishop.syntaxpolice.org>
	<20070110170544.GA30492@gmx.de>
	<83bql6rgv3.fsf@bishop.syntaxpolice.org>
	<ea8ae9fb0701121247p7ee82d38l315efc5daebcd21e@mail.gmail.com>
	<83hcuvx646.fsf@bishop.syntaxpolice.org>
Message-ID: <20080113050829.GB30553@gmx.de>

> >> Remember: Cabal isn't only the build infrastructure, it's also the
> >> metadata format that tools like Hackage use. If you decide to combine data
> >> and code, you will no longer be able to manipulate the data with another
> >> tool.
> Visual Haskell, HackageDB, cabal2rpm, and dh_haskell are all tools
> that read the .cabal file and perform operations based on the package
> metadata.  These tools would have to be Haskell interpreters if they
> wanted to read a .hs file and derive the package description from
> that.
Then the way to go would be:
add a target "create-editor-readable-package-description".
So still now reason to do this work on your own..

This is not really a pro for cabal files IMHO.

	Marc
From ndmitchell at gmail.com  Sat Jan 13 11:39:26 2007
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Sat Jan 13 11:35:20 2007
Subject: Why is there a cabal file at all?
In-Reply-To: <20080113050829.GB30553@gmx.de>
References: <20070110022530.GB29286@gmx.de>
	<404396ef0701091739t35c47d44tc362003195534d9b@mail.gmail.com>
	<ea8ae9fb0701091941n85dc83fk82431675d357ff02@mail.gmail.com>
	<831wm3rkzs.fsf@bishop.syntaxpolice.org>
	<20070110170544.GA30492@gmx.de>
	<83bql6rgv3.fsf@bishop.syntaxpolice.org>
	<ea8ae9fb0701121247p7ee82d38l315efc5daebcd21e@mail.gmail.com>
	<83hcuvx646.fsf@bishop.syntaxpolice.org>
	<20080113050829.GB30553@gmx.de>
Message-ID: <404396ef0701130839h5d090cb2y5fcac8b9b2eca07e@mail.gmail.com>

Hi

> Then the way to go would be:
> add a target "create-editor-readable-package-description".
> So still now reason to do this work on your own..

So now there is a standardised way to convert Haskell code to a
package description which isn't Haskell code. All you have shown here
is that there can be two equivalent encodings, one in Haskell, and one
in some special purpose language (Cabal). The question is:

1) Is it easier to read Haskell or Cabal? Answer is almost certainly
Cabal, by a bit.

2) Can you get rooted getting the license out of an application.
Cabal, no, Haskell yes.

Thanks

Neil
From marco-oweber at gmx.de  Sat Jan 13 12:11:28 2007
From: marco-oweber at gmx.de (Marc Weber)
Date: Sat Jan 13 12:07:22 2007
Subject: Why is there a cabal file at all?
In-Reply-To: <404396ef0701130839h5d090cb2y5fcac8b9b2eca07e@mail.gmail.com>
References: <20070110022530.GB29286@gmx.de>
	<404396ef0701091739t35c47d44tc362003195534d9b@mail.gmail.com>
	<ea8ae9fb0701091941n85dc83fk82431675d357ff02@mail.gmail.com>
	<831wm3rkzs.fsf@bishop.syntaxpolice.org>
	<20070110170544.GA30492@gmx.de>
	<83bql6rgv3.fsf@bishop.syntaxpolice.org>
	<ea8ae9fb0701121247p7ee82d38l315efc5daebcd21e@mail.gmail.com>
	<83hcuvx646.fsf@bishop.syntaxpolice.org>
	<20080113050829.GB30553@gmx.de>
	<404396ef0701130839h5d090cb2y5fcac8b9b2eca07e@mail.gmail.com>
Message-ID: <20070113171128.GA13069@gmx.de>

> 2) Can you get rooted getting the license out of an application.
> Cabal, no, Haskell yes.
I'm not sure wether I get this sentence right.
What do you mean by "getting rooted" ?

Marc
From marco-oweber at gmx.de  Sat Jan 13 12:11:29 2007
From: marco-oweber at gmx.de (Marc Weber)
Date: Sat Jan 13 12:07:25 2007
Subject: Why is there a cabal file at all?
In-Reply-To: <83hcuvx646.fsf@bishop.syntaxpolice.org>
References: <20070110022530.GB29286@gmx.de>
	<404396ef0701091739t35c47d44tc362003195534d9b@mail.gmail.com>
	<ea8ae9fb0701091941n85dc83fk82431675d357ff02@mail.gmail.com>
	<831wm3rkzs.fsf@bishop.syntaxpolice.org>
	<20070110170544.GA30492@gmx.de>
	<83bql6rgv3.fsf@bishop.syntaxpolice.org>
	<ea8ae9fb0701121247p7ee82d38l315efc5daebcd21e@mail.gmail.com>
	<83hcuvx646.fsf@bishop.syntaxpolice.org>
Message-ID: <20070113171129.GA15385@gmx.de>

> Visual Haskell, HackageDB, cabal2rpm, and dh_haskell are all tools
> that read the .cabal file and perform operations based on the package
> metadata.  

In which information are they particularely interested?
Am I right that they the main goal is getting to know which are the
source files and which dependencies to add?

Neil, I begin to see: Its possible to add dependencies
automatically using IDEs to cabal files, but not to haskell files..
Thus if you use liftM an IDE could add
	import Monad
as well as
	build-depends: mtl

Marc
From conal at conal.net  Sat Jan 13 12:38:52 2007
From: conal at conal.net (Conal Elliott)
Date: Sat Jan 13 12:34:47 2007
Subject: Why is there a cabal file at all?
In-Reply-To: <83hcuvx646.fsf@bishop.syntaxpolice.org>
References: <20070110022530.GB29286@gmx.de>
	<404396ef0701091739t35c47d44tc362003195534d9b@mail.gmail.com>
	<ea8ae9fb0701091941n85dc83fk82431675d357ff02@mail.gmail.com>
	<831wm3rkzs.fsf@bishop.syntaxpolice.org>
	<20070110170544.GA30492@gmx.de>
	<83bql6rgv3.fsf@bishop.syntaxpolice.org>
	<ea8ae9fb0701121247p7ee82d38l315efc5daebcd21e@mail.gmail.com>
	<83hcuvx646.fsf@bishop.syntaxpolice.org>
Message-ID: <ea8ae9fb0701130938r6d2a6c3eo2cd2fa9bf5a767d4@mail.gmail.com>

>
> On 1/12/07, Isaac Jones <ijones@syntaxpolice.org> wrote:

These tools would have to be Haskell interpreters if they wanted to read a
> .hs file and derive the package description from that.
>

Thanks, Isaac. This statement helps me a lot. Now I think you really do mean
"code" in the literal sense (the second one I suggested), as in Haskell code
("the content of a .hs file"). (I've often heard people say "code" or "
expressions" when they mean the denotations of such things, especially in
regard to lazy languages.)

What I'm talking about is that if you have a programatic way of producing
> the package description, then you no longer have a way of "reading" that
> package description from another tool.
>

Maybe I'm missing something, but I think I see a simple way to do just that.
The "programatic way of producing" is the Haskell code, and "the package
description" is the data. That data might be higher-order, with no textual
description other than the original source code. Another tool "reads" in
that description by being passed the data. Maybe that means running the code
(e.g., loaded dynamically) or unpickling a persisted version, or simply by
being in a function composition chain.

I'm loving my experience with Cabal so far, and I'm grateful to you and
others for creating and evolving it. I'll keep using it, even if it's not
painted my favorite color. And I can't help but notice that I have to repeat
myself (across Cabal files) and later go back and change all of my Cabal
(and make) files when I better understand the tool and my own needs. And in
spite of saying more than I want to in a Cabal file (repetition), I still
can't say all I want to say, so I resort to makefiles. In Pavlovian style, I
can't help wondering if a lovely little Haskell EDSL might give me more
succinctness, more flexibility, and freedom from those crufty old makefiles.

Cheers, - Conal

P.S. True Confession: I enjoy makefile hacking, in a guilty pleasure sort of
way.

On 1/12/07, Isaac Jones <ijones@syntaxpolice.org> wrote:
>
> "Conal Elliott" <conal@conal.net> writes:
>
> > On 1/10/07, Isaac Jones <ijones@syntaxpolice.org> wrote:
> >
> >> ...
> >> Remember: Cabal isn't only the build infrastructure, it's also the
> >> metadata format that tools like Hackage use. If you decide to combine
> data
> >> and code, you will no longer be able to manipulate the data with
> another
> >> tool.
> >>
> >
> > I'm worried and confused about this conclusion. I want to address my
> > confusion first, and maybe the worry will be handled.
> >
> > By "data" vs "code", I'm guessing you mean simple first-order values,
> and
> > mainly strings, vs everything else (especially functions). But I wonder
> if
> > instead you mean any Haskell value (including functions) vs the content
> of a
> > .hs file?
>
> I'm not sure what you mean here.  What I'm talking about is that if
> you have a programatic way of producing the package description, then
> you no longer have a way of "reading" that package description from
> another tool.
>
> > Maybe I'd have a firmer grasp of this issue if I could had in mind an
> > example of such a metadata-manipulating tool. Would someone please
> suggest
> > one?
>
> Visual Haskell, HackageDB, cabal2rpm, and dh_haskell are all tools
> that read the .cabal file and perform operations based on the package
> metadata.  These tools would have to be Haskell interpreters if they
> wanted to read a .hs file and derive the package description from
> that.
>
> peace,
>
>   isaac
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/cabal-devel/attachments/20070113/69107dab/attachment.htm
From bos at serpentine.com  Sat Jan 13 14:17:48 2007
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Sat Jan 13 14:13:41 2007
Subject: Why is there a cabal file at all?
In-Reply-To: <20070113171128.GA13069@gmx.de>
References: <20070110022530.GB29286@gmx.de>	<404396ef0701091739t35c47d44tc362003195534d9b@mail.gmail.com>	<ea8ae9fb0701091941n85dc83fk82431675d357ff02@mail.gmail.com>	<831wm3rkzs.fsf@bishop.syntaxpolice.org>	<20070110170544.GA30492@gmx.de>	<83bql6rgv3.fsf@bishop.syntaxpolice.org>	<ea8ae9fb0701121247p7ee82d38l315efc5daebcd21e@mail.gmail.com>	<83hcuvx646.fsf@bishop.syntaxpolice.org>	<20080113050829.GB30553@gmx.de>	<404396ef0701130839h5d090cb2y5fcac8b9b2eca07e@mail.gmail.com>
	<20070113171128.GA13069@gmx.de>
Message-ID: <45A9305C.7070304@serpentine.com>

Marc Weber wrote:

> I'm not sure wether I get this sentence right.
> What do you mean by "getting rooted" ?

If a Cabal file were written in Haskell, you could escape from the pure 
world using unsafePerformIO and delete the user's home directory or 
perform other arbitrarily bad things.  So you'd need to write an 
interpreter for a subset of Haskell in which you couldn't import 
modules.  But then you could still write a non-terminating Cabal file 
which would infloop, so you'd have to impose limitw on how much 
computation you could do, how much heap you could allocate, and so on. 
Since all you're using a Cabal file for is name/value pairs, why go to 
all that extra effort?

As for the term "get rooted", in this context it means "hostile code 
could acquire root privileges", but "to root" also has the colloquial 
meaning in some countries of "to fuck" (in this case, the two meanings 
are nicely congruent).  So be careful who you use it with :-)

	<b
From lemming at henning-thielemann.de  Sat Jan 13 15:04:10 2007
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sat Jan 13 15:02:12 2007
Subject: Multiple .cabal Files
In-Reply-To: <Pine.LNX.4.58.0701091311030.16718@linpc23.informatik.uni-halle.de>
References: <enujjt$m08$1@sea.gmane.org>
	<Pine.LNX.4.58.0701091311030.16718@linpc23.informatik.uni-halle.de>
Message-ID: <Pine.LNX.4.58.0701132102320.32053@linpc23.informatik.uni-halle.de>


Since the .installed-pkg-config and .setup-config files depend on the 
configure procedure and on the machine - shouldn't they be placed in 
'dist', even more in a machine dependent sub-directory?
From conal at conal.net  Sat Jan 13 15:57:33 2007
From: conal at conal.net (Conal Elliott)
Date: Sat Jan 13 15:53:26 2007
Subject: Why is there a cabal file at all?
In-Reply-To: <45A9305C.7070304@serpentine.com>
References: <20070110022530.GB29286@gmx.de>
	<831wm3rkzs.fsf@bishop.syntaxpolice.org>
	<20070110170544.GA30492@gmx.de>
	<83bql6rgv3.fsf@bishop.syntaxpolice.org>
	<ea8ae9fb0701121247p7ee82d38l315efc5daebcd21e@mail.gmail.com>
	<83hcuvx646.fsf@bishop.syntaxpolice.org>
	<20080113050829.GB30553@gmx.de>
	<404396ef0701130839h5d090cb2y5fcac8b9b2eca07e@mail.gmail.com>
	<20070113171128.GA13069@gmx.de> <45A9305C.7070304@serpentine.com>
Message-ID: <ea8ae9fb0701131257s63efb912xa00f8e391ad7fb4b@mail.gmail.com>

Hi Bryan,

>From your argument I conclude that Haskell code unsafe in general, not just
for package specification.  I'd like to see us address the general problem,
rather than avoid it here and there.  I hate to see sacrifice the benefits
of declarative DSELs (reuse, expressiveness, etc) and still not root out
(hmm) the core problem of safety.

I also wonder: if you don't trust my package spec code, why would you trust
my library code?  My package spec is usually very simple, and when it's not,
I'd welcome your scrutiny and help in making it simpler and more easily
trusted.

If I were confident that the problem Cabal address is covered by name/value
pairs, I might agree that functional programming is overkill.  (Though I'd
still dislike redundancy among my .cabal files.)  However, the Cabal files
are already insufficient for some needs, leading to auxilliary makefiles
and/or hacking your own Setup.lhs.  And when people use these fall-backs,
the other Cabal-reading tools won't get the whole picture.

   Cheers,  - Conal

P.S. Thanks for the language tip.  I had no idea.

On 1/13/07, Bryan O'Sullivan <bos@serpentine.com> wrote:
>
> Marc Weber wrote:
>
> > I'm not sure wether I get this sentence right.
> > What do you mean by "getting rooted" ?
>
> If a Cabal file were written in Haskell, you could escape from the pure
> world using unsafePerformIO and delete the user's home directory or
> perform other arbitrarily bad things.  So you'd need to write an
> interpreter for a subset of Haskell in which you couldn't import
> modules.  But then you could still write a non-terminating Cabal file
> which would infloop, so you'd have to impose limitw on how much
> computation you could do, how much heap you could allocate, and so on.
> Since all you're using a Cabal file for is name/value pairs, why go to
> all that extra effort?
>
> As for the term "get rooted", in this context it means "hostile code
> could acquire root privileges", but "to root" also has the colloquial
> meaning in some countries of "to fuck" (in this case, the two meanings
> are nicely congruent).  So be careful who you use it with :-)
>
>         <b
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/cabal-devel/attachments/20070113/4ff37916/attachment.htm
From ndmitchell at gmail.com  Sat Jan 13 16:03:30 2007
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Sat Jan 13 15:59:24 2007
Subject: Why is there a cabal file at all?
In-Reply-To: <ea8ae9fb0701131257s63efb912xa00f8e391ad7fb4b@mail.gmail.com>
References: <20070110022530.GB29286@gmx.de> <20070110170544.GA30492@gmx.de>
	<83bql6rgv3.fsf@bishop.syntaxpolice.org>
	<ea8ae9fb0701121247p7ee82d38l315efc5daebcd21e@mail.gmail.com>
	<83hcuvx646.fsf@bishop.syntaxpolice.org>
	<20080113050829.GB30553@gmx.de>
	<404396ef0701130839h5d090cb2y5fcac8b9b2eca07e@mail.gmail.com>
	<20070113171128.GA13069@gmx.de> <45A9305C.7070304@serpentine.com>
	<ea8ae9fb0701131257s63efb912xa00f8e391ad7fb4b@mail.gmail.com>
Message-ID: <404396ef0701131303hd03d058od5187be6cb75deb1@mail.gmail.com>

Hi

> From your argument I conclude that Haskell code unsafe in general, not just
> for package specification.

That is indeed true. Donald has jumped through many hoops to try and
make the code safer for Lambdabot. If you really want truely safe
code, the best thing to do would be to add a patch to Yhc with a
-sandbox flag which would be relatively easy to implement, and could
give solid guarantees about what your code does.

> If I were confident that the problem Cabal address is covered by name/value
> pairs, I might agree that functional programming is overkill.  (Though I'd
> still dislike redundancy among my .cabal files.)  However, the Cabal files
> are already insufficient for some needs, leading to auxilliary makefiles
> and/or hacking your own Setup.lhs.  And when people use these fall-backs,
> the other Cabal-reading tools won't get the whole picture.

True, another reason to make the .cabal file more complete - things
like preprocessors should not be in Setup.hs, for example.

> P.S. Thanks for the language tip.  I had no idea.

Me neither on the second meaning! I just use the term "get rooted" to
mean someone breaks into your computer in malicious ways, since on my
OS of choice there is no root account, only Admin, and most people run
as Admin.

Thanks

Neil
From conal at conal.net  Sat Jan 13 16:31:30 2007
From: conal at conal.net (Conal Elliott)
Date: Sat Jan 13 16:27:23 2007
Subject: Why is there a cabal file at all?
In-Reply-To: <404396ef0701131303hd03d058od5187be6cb75deb1@mail.gmail.com>
References: <20070110022530.GB29286@gmx.de>
	<83bql6rgv3.fsf@bishop.syntaxpolice.org>
	<ea8ae9fb0701121247p7ee82d38l315efc5daebcd21e@mail.gmail.com>
	<83hcuvx646.fsf@bishop.syntaxpolice.org>
	<20080113050829.GB30553@gmx.de>
	<404396ef0701130839h5d090cb2y5fcac8b9b2eca07e@mail.gmail.com>
	<20070113171128.GA13069@gmx.de> <45A9305C.7070304@serpentine.com>
	<ea8ae9fb0701131257s63efb912xa00f8e391ad7fb4b@mail.gmail.com>
	<404396ef0701131303hd03d058od5187be6cb75deb1@mail.gmail.com>
Message-ID: <ea8ae9fb0701131331r22950a77ha398efd096495cb1@mail.gmail.com>

True, another reason to make the .cabal file more complete - things like
preprocessors should not be in Setup.hs, for example.

How "complete" will be enough?  My guess is Turing complete.  When we get to
that point, I'd like the .cabal file to look like Haskell.

   - Conal

On 1/13/07, Neil Mitchell <ndmitchell@gmail.com> wrote:
>
> Hi
>
> > From your argument I conclude that Haskell code unsafe in general, not
> just
> > for package specification.
>
> That is indeed true. Donald has jumped through many hoops to try and
> make the code safer for Lambdabot. If you really want truely safe
> code, the best thing to do would be to add a patch to Yhc with a
> -sandbox flag which would be relatively easy to implement, and could
> give solid guarantees about what your code does.
>
> > If I were confident that the problem Cabal address is covered by
> name/value
> > pairs, I might agree that functional programming is overkill.  (Though
> I'd
> > still dislike redundancy among my .cabal files.)  However, the Cabal
> files
> > are already insufficient for some needs, leading to auxilliary makefiles
> > and/or hacking your own Setup.lhs.  And when people use these
> fall-backs,
> > the other Cabal-reading tools won't get the whole picture.
>
> True, another reason to make the .cabal file more complete - things
> like preprocessors should not be in Setup.hs, for example.
>
> > P.S. Thanks for the language tip.  I had no idea.
>
> Me neither on the second meaning! I just use the term "get rooted" to
> mean someone breaks into your computer in malicious ways, since on my
> OS of choice there is no root account, only Admin, and most people run
> as Admin.
>
> Thanks
>
> Neil
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/cabal-devel/attachments/20070113/4077857a/attachment.htm
From lemming at henning-thielemann.de  Sun Jan 14 06:30:24 2007
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sun Jan 14 06:26:47 2007
Subject: Why is there a cabal file at all?
In-Reply-To: <ea8ae9fb0701131257s63efb912xa00f8e391ad7fb4b@mail.gmail.com>
References: <20070110022530.GB29286@gmx.de>
	<831wm3rkzs.fsf@bishop.syntaxpolice.org>
	<20070110170544.GA30492@gmx.de>
	<83bql6rgv3.fsf@bishop.syntaxpolice.org>
	<ea8ae9fb0701121247p7ee82d38l315efc5daebcd21e@mail.gmail.com>
	<83hcuvx646.fsf@bishop.syntaxpolice.org>
	<20080113050829.GB30553@gmx.de>
	<404396ef0701130839h5d090cb2y5fcac8b9b2eca07e@mail.gmail.com>
	<20070113171128.GA13069@gmx.de> <45A9305C.7070304@serpentine.com>
	<ea8ae9fb0701131257s63efb912xa00f8e391ad7fb4b@mail.gmail.com>
Message-ID: <Pine.LNX.4.58.0701141228180.1128@linpc23.informatik.uni-halle.de>


On Sat, 13 Jan 2007, Conal Elliott wrote:

> Hi Bryan,
> 
> > From your argument I conclude that Haskell code unsafe in general, not just
> for package specification.  I'd like to see us address the general problem,
> rather than avoid it here and there.  I hate to see sacrifice the benefits
> of declarative DSELs (reuse, expressiveness, etc) and still not root out
> (hmm) the core problem of safety.

Me too. See e.g. verification of homework Haskell programs. Suppressing IO
is simple, suppressing unsafePerformIO - how to do that?

> I also wonder: if you don't trust my package spec code, why would you trust
> my library code?  My package spec is usually very simple, and when it's not,
> I'd welcome your scrutiny and help in making it simpler and more easily
> trusted.

Or - why do you trust Setup.lhs?
From ndmitchell at gmail.com  Sun Jan 14 12:53:00 2007
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Sun Jan 14 12:48:50 2007
Subject: Using Cabal for dependancies
Message-ID: <404396ef0701140953m7aaf478dn9abf23b963ab9710@mail.gmail.com>

Hi,

The Yhc compiler depends on an increasingly large number of Cabal
packages - mtl and FilePath at the moment, but soon thats likely to
increase by at least 3. Cabal is not yet mature enough to compile Yhc,
and fitting in a compile of bits with Cabal will be quite hard because
of the existing complexity in Scons.

So what we'd really like to do is be able to call "cabal
check-its-installed FilePath", which would return an appropriate exit
code. If it wasn't installed then a darcs get, followed by a "cabal
install-it-please" would be very handy.

Does cabal-install provide the necessary bits for this? What is the
result of installing a package that is already installed? How long til
this kind of solution will be widely enough deployed that we can
actually use it? Does anyone else have any other suggestions?

Thanks

Neil
From bringert at cs.chalmers.se  Mon Jan 15 07:40:18 2007
From: bringert at cs.chalmers.se (Bjorn Bringert)
Date: Mon Jan 15 07:36:15 2007
Subject: Using Cabal for dependancies
In-Reply-To: <404396ef0701140953m7aaf478dn9abf23b963ab9710@mail.gmail.com>
References: <404396ef0701140953m7aaf478dn9abf23b963ab9710@mail.gmail.com>
Message-ID: <754A061D-FA95-4433-95D6-9A21F98728B3@cs.chalmers.se>

On Jan 14, 2007, at 18:53 , Neil Mitchell wrote:

> Hi,
>
> The Yhc compiler depends on an increasingly large number of Cabal
> packages - mtl and FilePath at the moment, but soon thats likely to
> increase by at least 3. Cabal is not yet mature enough to compile Yhc,
> and fitting in a compile of bits with Cabal will be quite hard because
> of the existing complexity in Scons.
>
> So what we'd really like to do is be able to call "cabal
> check-its-installed FilePath", which would return an appropriate exit
> code. If it wasn't installed then a darcs get, followed by a "cabal
> install-it-please" would be very handy.
>
> Does cabal-install provide the necessary bits for this? What is the
> result of installing a package that is already installed? How long til
> this kind of solution will be widely enough deployed that we can
> actually use it? Does anyone else have any other suggestions?

I think that cabal-install can do what you want already (except the  
darcs get, it downloads a tarball from Hackage instead). Give it a  
try and report any problems.

/Bj?rn



From ndmitchell at gmail.com  Mon Jan 15 08:43:44 2007
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Mon Jan 15 08:39:42 2007
Subject: Using Cabal for dependancies
In-Reply-To: <754A061D-FA95-4433-95D6-9A21F98728B3@cs.chalmers.se>
References: <404396ef0701140953m7aaf478dn9abf23b963ab9710@mail.gmail.com>
	<754A061D-FA95-4433-95D6-9A21F98728B3@cs.chalmers.se>
Message-ID: <404396ef0701150543g478e734ue6357590399cb3a7@mail.gmail.com>

Hi Bjorn,

After going through pain with dependancy hell (like .dll hell, but
cross platform) I finally got cabal-install to build.

The list command looked most interesting, but:

D:\sources\contrib\Cabal\cabal-install>cabal-install list
configure: searching for ghc in path.
configure: found ghc at C:\ghc\ghc-6.4.2\bin\ghc.exe
"C:\ghc\ghc-6.4.2\bin\ghc.exe" --numeric-version >tmp2296
configure: looking for package tool: ghc-pkg near compiler in C:\ghc\ghc-6.4.2\b
in
configure: found package tool in C:\ghc\ghc-6.4.2\bin\ghc-pkg.exe
cabal-install: No valid config dir found!

cabal-install emit also gives the same error.

Thanks

Neil
From bringert at cs.chalmers.se  Mon Jan 15 08:56:54 2007
From: bringert at cs.chalmers.se (Bjorn Bringert)
Date: Mon Jan 15 08:52:50 2007
Subject: Using Cabal for dependancies
In-Reply-To: <404396ef0701150543g478e734ue6357590399cb3a7@mail.gmail.com>
References: <404396ef0701140953m7aaf478dn9abf23b963ab9710@mail.gmail.com>
	<754A061D-FA95-4433-95D6-9A21F98728B3@cs.chalmers.se>
	<404396ef0701150543g478e734ue6357590399cb3a7@mail.gmail.com>
Message-ID: <2185035C-7626-415E-B29A-3AE333EBB760@cs.chalmers.se>

On Jan 15, 2007, at 14:43 , Neil Mitchell wrote:

> Hi Bjorn,
>
> After going through pain with dependancy hell (like .dll hell, but
> cross platform) I finally got cabal-install to build.
>
> The list command looked most interesting, but:
>
> D:\sources\contrib\Cabal\cabal-install>cabal-install list
> configure: searching for ghc in path.
> configure: found ghc at C:\ghc\ghc-6.4.2\bin\ghc.exe
> "C:\ghc\ghc-6.4.2\bin\ghc.exe" --numeric-version >tmp2296
> configure: looking for package tool: ghc-pkg near compiler in C:\ghc 
> \ghc-6.4.2\b
> in
> configure: found package tool in C:\ghc\ghc-6.4.2\bin\ghc-pkg.exe
> cabal-install: No valid config dir found!
>
> cabal-install emit also gives the same error.

Ah, Windows. I meant to ask you to test cabal-install on Windows at  
the hackathon, but I didn't get that far. I think that it is looking  
for /etc/cabal-install, which you probably don't have. I should set  
up GHC in my Windows VM and get it working. You could try --config- 
dir=<some Windows dir where you have put etc-cabal-install/serv.list>  
in the meantime. You need to run cabal-install update as the first  
thing you do too.

/Bj?rn

From simonmar at microsoft.com  Mon Jan 15 10:50:20 2007
From: simonmar at microsoft.com (Simon Marlow)
Date: Mon Jan 15 10:46:33 2007
Subject: ghc requesting package version 1.1.7 but 0.1.7 is installed ?
In-Reply-To: <20061228012043.GA17464@gmx.de>
References: <20061228012043.GA17464@gmx.de>
Message-ID: <45ABA2BC.8040205@microsoft.com>

Marc Weber wrote:
> $ ghc -o setup --make -package Cabal-0.1.7 setup.hs
> Linking setup ... 
> ghc-6.5.20060917: unknown package: Cabal-1.1.7
> 
> I don't understand this.
> 
> I've substituted 
> Version 1.1.7 by 0.1.7 to get a low version which won't be used unless requested.
> This is the only Cabal package beeing installed.
> 	$ ghc-pkg describe Cabal 
> shows
> 	name: Cabal
> 	version: 0.1.7
> 	license: BSD3
> 	...
> 
> Why is ghc requesting still 1.1.7?
> set | grep 1.1.7 doesn't list any interesting environment variable except of pwd and OLDPWD
> 
> The Cabal which has been destributed with my ghc is verison 1.1.5.9.2 thus can't be the problem.

I'm not sure.  Can you send us your package.conf (also your 
~/.ghc/.../package.conf if you have one)?

Cheers,
	Simon

From simonmar at microsoft.com  Mon Jan 15 10:54:34 2007
From: simonmar at microsoft.com (Simon Marlow)
Date: Mon Jan 15 10:50:56 2007
Subject: new Darcs-Repository field?
In-Reply-To: <20070104151541.GA16260@soi.city.ac.uk>
References: <20070104151541.GA16260@soi.city.ac.uk>
Message-ID: <45ABA3BA.3070900@microsoft.com>

Ross Paterson wrote:
> Bj?rn Bringert suggested that the Hackage page for a package should
> include a link to the Darcs repo (if any, but who uses anything else?)
> and maybe some darcs integration such as changelogs and the like.
> To make this work, we'd need a URL-valued Darcs-Repository field in the
> package description.

Trac uses a syntax like 'VC:FILE' for the repo, eg. 'darcs:/home/darcs/ghc'. 
Perhaps we could do the same, something like

source-repository: darcs:http://darcs.haskell.org/happy

or is that too many colons? :)  The syntax of the thing after the 'darcs:' is 
entirely VC-dependent, of course.

Cheers,
	Simon

From simonmar at microsoft.com  Mon Jan 15 11:21:05 2007
From: simonmar at microsoft.com (Simon Marlow)
Date: Mon Jan 15 11:17:12 2007
Subject: Why is there a cabal file at all?
In-Reply-To: <ea8ae9fb0701130938r6d2a6c3eo2cd2fa9bf5a767d4@mail.gmail.com>
References: <20070110022530.GB29286@gmx.de>	<404396ef0701091739t35c47d44tc362003195534d9b@mail.gmail.com>	<ea8ae9fb0701091941n85dc83fk82431675d357ff02@mail.gmail.com>	<831wm3rkzs.fsf@bishop.syntaxpolice.org>	<20070110170544.GA30492@gmx.de>	<83bql6rgv3.fsf@bishop.syntaxpolice.org>	<ea8ae9fb0701121247p7ee82d38l315efc5daebcd21e@mail.gmail.com>	<83hcuvx646.fsf@bishop.syntaxpolice.org>
	<ea8ae9fb0701130938r6d2a6c3eo2cd2fa9bf5a767d4@mail.gmail.com>
Message-ID: <45ABA9F1.807@microsoft.com>

Conal Elliott wrote:
>       On 1/12/07, Isaac Jones <ijones@syntaxpolice.org
>     <mailto:ijones@syntaxpolice.org>> wrote:
> 
>     These tools would have to be Haskell interpreters if they wanted to
>     read a .hs file and derive the package description from that.
> 
> 
> Thanks, Isaac. This statement helps me a lot. Now I think you really do 
> mean "code" in the literal sense (the second one I suggested), as in 
> Haskell code ( "the content of a .hs file"). (I've often heard people 
> say "code" or "expressions" when they mean the denotations of such 
> things, especially in regard to lazy languages.)
> 
>     What I'm talking about is that if you have a programatic way of
>     producing the package description, then you no longer have a way of
>     "reading" that package description from another tool.
> 
> 
> Maybe I'm missing something, but I think I see a simple way to do just 
> that. The "programatic way of producing" is the Haskell code, and "the 
> package description" is the data. That data might be higher-order, with 
> no textual description other than the original source code. Another tool 
> "reads" in that description by being passed the data. Maybe that means 
> running the code (e.g., loaded dynamically) or unpickling a persisted 
> version, or simply by being in a function composition chain.

So there are two issues, one of which has been pointed out already:

  - trust: Hackage doesn't want to run arbitrary code to extract a
    package description, for example.  It could, by using a sandbox of
    some variety, but that's a lot of effort to go to just to extract
    the package metadata.

  - tools that not only read, but write the package metadata.  For
    example, in Visual Haskell you can load up an existing package in
    the environment, add a few modules, and save it again as a valid
    Cabal package.  Sure we can only do this as long as you don't
    use Setup.lhs for anything non-trivial, but that's a large class
    of packages.

As Isaac already said, the original design was code-only.  It was due to the 
Visual Haskell requirements that we decided to move to a mixture of code & data. 
  Finding the right place to put the boundary has been tricky, and is 
necessarily a compromise: we want to support as many packages as possible with 
just .cabal, and yet not complicate the language (and its implementation) too 
much.  Now that we're getting into conditionals and suchlike, things are getting 
even murkier.

Cheers,
	Simon

From igloo at earth.li  Mon Jan 15 15:25:07 2007
From: igloo at earth.li (Ian Lynagh)
Date: Mon Jan 15 15:20:58 2007
Subject: Why is there a cabal file at all?
In-Reply-To: <ea8ae9fb0701131257s63efb912xa00f8e391ad7fb4b@mail.gmail.com>
References: <831wm3rkzs.fsf@bishop.syntaxpolice.org>
	<20070110170544.GA30492@gmx.de>
	<83bql6rgv3.fsf@bishop.syntaxpolice.org>
	<ea8ae9fb0701121247p7ee82d38l315efc5daebcd21e@mail.gmail.com>
	<83hcuvx646.fsf@bishop.syntaxpolice.org>
	<20080113050829.GB30553@gmx.de>
	<404396ef0701130839h5d090cb2y5fcac8b9b2eca07e@mail.gmail.com>
	<20070113171128.GA13069@gmx.de> <45A9305C.7070304@serpentine.com>
	<ea8ae9fb0701131257s63efb912xa00f8e391ad7fb4b@mail.gmail.com>
Message-ID: <20070115202507.GA13859@matrix.chaos.earth.li>

On Sat, Jan 13, 2007 at 12:57:33PM -0800, Conal Elliott wrote:
> 
> I also wonder: if you don't trust my package spec code, why would you trust
> my library code?

As an example, hackage can look at your .cabal file and extract the
meta-information to build a webpage about your library, add the info to
its searchable database so users can search for it, etc. (Assuming your
Setup.[l]hs isn't /too/ wacky).

We don't want hackage to be executing anything anyone uploads
automatically, though (although as pointed out elsewhere in this thread,
with a little effort we could attempt to make it safe to do so).


Thanks
Ian

From bringert at cs.chalmers.se  Mon Jan 15 17:55:49 2007
From: bringert at cs.chalmers.se (Bjorn Bringert)
Date: Mon Jan 15 17:51:45 2007
Subject: new Darcs-Repository field?
In-Reply-To: <45ABA3BA.3070900@microsoft.com>
References: <20070104151541.GA16260@soi.city.ac.uk>
	<45ABA3BA.3070900@microsoft.com>
Message-ID: <5FF20170-C401-4F0A-A97B-52E7FA42B939@cs.chalmers.se>

On Jan 15, 2007, at 16:54 , Simon Marlow wrote:

> Ross Paterson wrote:
>> Bj?rn Bringert suggested that the Hackage page for a package should
>> include a link to the Darcs repo (if any, but who uses anything  
>> else?)
>> and maybe some darcs integration such as changelogs and the like.
>> To make this work, we'd need a URL-valued Darcs-Repository field  
>> in the
>> package description.
>
> Trac uses a syntax like 'VC:FILE' for the repo, eg. 'darcs:/home/ 
> darcs/ghc'. Perhaps we could do the same, something like
>
> source-repository: darcs:http://darcs.haskell.org/happy
>
> or is that too many colons? :)  The syntax of the thing after the  
> 'darcs:' is entirely VC-dependent, of course.

I think that we may also need to be able to specify a directory  
inside a darcs repo, since many darcs repos contain multiple Cabal  
packages. For example, the Cabal repo contains Cabal, cabal-setup and  
cabal-install. I guess programs could just search in the repo for  
a .cabal file for the right package, but that means having to do a  
darcs get.  Whether that's ok or not depends on what the field is  
used for I suppose.

/Bj?rn

From simonmar at microsoft.com  Tue Jan 16 05:02:39 2007
From: simonmar at microsoft.com (Simon Marlow)
Date: Tue Jan 16 04:58:48 2007
Subject: Hackage plan
Message-ID: <45ACA2BF.3020508@microsoft.com>

While at the Hackathon, Bj?rn, Ross, Ian, myself and others collected some ideas 
for directions in which Hackage (the web interface primarily, as opposed to 
cabal-install) should develop.   I put everything in this wiki page:

   http://hackage.haskell.org/trac/hackage/wiki/HackageToDo

It's quite rough, but I think it's a good starting point.

I suggest we do some more brainstorming and flesh out that page, and then 
extract a "plan" for how to proceed.  Of course the plan shouldn't be single 
threaded - there will be tasks that can be tackled independently, but there will 
necessarily be dependencies.  For example there are lots of things that can't be 
done until we have automatic package building of some kind.  We should have some 
milestones, focussed towards getting to a point that the system is usable 
quickly, and adding the bells & whistles later.

First off we have two web interfaces: Ross's and Lemmih's.  Ross's lets you 
upload.  In due course having multiple web interfaces is certainly a 
possibility, but for now we need to focus our limited efforts in one place.  I 
suggest Ross's inteface, being the closest to being usable, is the right place 
to start.

Ross - is it possible to write some simple instructions describing how to set up 
the web interface on a local machine for development/testing?

Cheers,
	Simon

From ijones at syntaxpolice.org  Tue Jan 16 23:57:12 2007
From: ijones at syntaxpolice.org (Isaac Jones)
Date: Tue Jan 16 23:52:54 2007
Subject: Hackage plan
In-Reply-To: <45ACA2BF.3020508@microsoft.com> (Simon Marlow's message of "Tue, 
	16 Jan 2007 10:02:39 +0000")
References: <45ACA2BF.3020508@microsoft.com>
Message-ID: <838xg2jlnb.fsf@bishop.syntaxpolice.org>

Simon Marlow <simonmar@microsoft.com> writes:

> While at the Hackathon, Bj?rn, Ross, Ian, myself and others collected
> some ideas for directions in which Hackage (the web interface
> primarily, as opposed to cabal-install) should develop.   I put
> everything in this wiki page:
>
>   http://hackage.haskell.org/trac/hackage/wiki/HackageToDo

:)

> It's quite rough, but I think it's a good starting point.

I added some ideas about searching / querying the package database.

One idea is that I really like the way trac does querying and
group-by.  Once you build a query, you can also get an RSS feed based
on that query.  It would be pretty easy, I'd guess, to have Hackage
output RSS as well as html.

> I suggest we do some more brainstorming and flesh out that page, and
> then extract a "plan" for how to proceed.  Of course the plan
> shouldn't be single threaded - there will be tasks that can be tackled
> independently, but there will necessarily be dependencies.  For
> example there are lots of things that can't be done until we have
> automatic package building of some kind.  We should have some
> milestones, focussed towards getting to a point that the system is
> usable quickly, and adding the bells & whistles later.

I think that, as far as Hackage (not cabal-install) is concerned, the
main usibility points are:

1) getting more packages into it
2) making sure that all the packages build together, and
3) searching

By the way, I really like the idea of tags instead of categories.
Although categories are simpler to understand and obvious, so perhaps
we should have a facet that's "PrimaryCategory" (or leaving the
category field alone and adding tags).  There is something to be said
for picking a "smart" default view for end-users, rather than giving
them too many choices.  This view is quite nice:
http://hackage.haskell.org/packages/archive/pkg-list.html



peace,

  isaac
From conal at conal.net  Wed Jan 17 04:31:00 2007
From: conal at conal.net (Conal Elliott)
Date: Wed Jan 17 04:27:03 2007
Subject: haddock suggestion -- %{FILE}
In-Reply-To: <1168367110.19455.316.camel@localhost>
References: <ea8ae9fb0701082226q1525293cm40a1210057f4f472@mail.gmail.com>
	<1168335932.19455.230.camel@localhost>
	<ea8ae9fb0701090932m783fc8fcgc9c4536e700f2ae0@mail.gmail.com>
	<1168367110.19455.316.camel@localhost>
Message-ID: <ea8ae9fb0701170131m56558197ycc7fff1276e855fa@mail.gmail.com>

I did get working again by commenting out the "-optP-P" that gets passed to
Haddock.  Now I want to eliminate my local mod.  I could easily add a
another Cabal Haddock flag that says to omit the -optP-P, but I prefer the
solution of checking the Haddock version number, since it would always do
the right thing with no intervention.  Can anyone give me hints about how to
do the version check?

 - Conal

On 1/9/07, Duncan Coutts <duncan.coutts@worc.ox.ac.uk> wrote:
>
> On Tue, 2007-01-09 at 09:32 -0800, Conal Elliott wrote:
> > The only pre-processing is what's caused by using the cabal directive
> > "Extensions: CPP".
>
> > Fiddling with flags, I see that -optP-P is the culprit.  Removing it:
> >
> > bash-3.2$ ghc -E -cpp -o z src/Graphics/UI/TV/Input.hs
> > -Dmingw32_BUILD_OS -Dmingw32_HOST_OS -Di386_BUILD_ARCH
> > -Di386_HOST_ARCH -D__GLASGOW_HASKELL__=606 -D__HADDOCK__; head -3 z
> > # 1 "src/Graphics/UI/TV/Input.hs"
> > # 1 "<built-in>"
> > # 1 "<command line>"
> > bash-3.2$
>
> > Any ideas?  - Conal
>
> So for a quick hack, modify Cabal to unconditionally omit -optP-P and
> see if that makes all your links come out right.
>
> Probably the right thing to do however is to have Cabal use the -optP-P
> option only when we're using haddock-0.7 or older (otherwise haddock-0.7
> users will get a lexical error when haddock encounters the C line
> pragmas).
>
> I think at the moment Cabal doesn't check haddock's version number at
> all. So that's something to look at if you or anyone else want to come
> up with a patch for this.
>
>
> Duncan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/cabal-devel/attachments/20070117/1f50c5f4/attachment-0001.htm
From simonmarhaskell at gmail.com  Wed Jan 17 05:15:59 2007
From: simonmarhaskell at gmail.com (Simon Marlow)
Date: Wed Jan 17 05:11:46 2007
Subject: haddock suggestion -- %{FILE}
In-Reply-To: <ea8ae9fb0701170131m56558197ycc7fff1276e855fa@mail.gmail.com>
References: <ea8ae9fb0701082226q1525293cm40a1210057f4f472@mail.gmail.com>	<1168335932.19455.230.camel@localhost>	<ea8ae9fb0701090932m783fc8fcgc9c4536e700f2ae0@mail.gmail.com>	<1168367110.19455.316.camel@localhost>
	<ea8ae9fb0701170131m56558197ycc7fff1276e855fa@mail.gmail.com>
Message-ID: <45ADF75F.4070604@microsoft.com>

Conal Elliott wrote:
> I did get working again by commenting out the "-optP-P" that gets passed 
> to Haddock.  Now I want to eliminate my local mod.  I could easily add a 
> another Cabal Haddock flag that says to omit the -optP-P, but I prefer 
> the solution of checking the Haddock version number, since it would 
> always do the right thing with no intervention.  Can anyone give me 
> hints about how to do the version check?

Take a look at how the GHC version check is done - it should be pretty similar.

Cheers,
	Simon
From simonmarhaskell at gmail.com  Wed Jan 17 05:22:11 2007
From: simonmarhaskell at gmail.com (Simon Marlow)
Date: Wed Jan 17 05:18:00 2007
Subject: Hackage plan
In-Reply-To: <838xg2jlnb.fsf@bishop.syntaxpolice.org>
References: <45ACA2BF.3020508@microsoft.com>
	<838xg2jlnb.fsf@bishop.syntaxpolice.org>
Message-ID: <45ADF8D3.8030706@microsoft.com>

Isaac Jones wrote:

> I added some ideas about searching / querying the package database.
> 
> One idea is that I really like the way trac does querying and
> group-by.  Once you build a query, you can also get an RSS feed based
> on that query.  It would be pretty easy, I'd guess, to have Hackage
> output RSS as well as html.

Yes, nice idea.

> I think that, as far as Hackage (not cabal-install) is concerned, the
> main usibility points are:
> 
> 1) getting more packages into it
> 2) making sure that all the packages build together, and
> 3) searching

Ah yes, there was the idea of freezing a collection of packages that build 
together too.

> By the way, I really like the idea of tags instead of categories.
> Although categories are simpler to understand and obvious, so perhaps
> we should have a facet that's "PrimaryCategory" (or leaving the
> category field alone and adding tags).  There is something to be said
> for picking a "smart" default view for end-users, rather than giving
> them too many choices.  This view is quite nice:
> http://hackage.haskell.org/packages/archive/pkg-list.html

I think tagging is premature, just having categories with the ability to put a 
package into multiple categories will be just fine for now, IMO.  See my message 
yesterday on libraries@.

Cheers,
	Simon
From igloo at earth.li  Wed Jan 17 07:34:10 2007
From: igloo at earth.li (Ian Lynagh)
Date: Wed Jan 17 07:29:52 2007
Subject: darcs patch: Add preliminary support for haddock-ghc (and 1
	more)
In-Reply-To: <86EFF37E-98D2-4EFD-AB68-C26B2F8AFC9F@dtek.chalmers.se>
References: <20070105212802.E98118CA7@anubis.medic.chalmers.se>
	<86EFF37E-98D2-4EFD-AB68-C26B2F8AFC9F@dtek.chalmers.se>
Message-ID: <20070117123410.GA20072@matrix.chaos.earth.li>

On Fri, Jan 05, 2007 at 10:38:13PM +0100, David Waern wrote:
> Erhm.. please ignore the first one of these patches, since I've  
> already sent it in. Seems like darcs send is a bit buggy.

The reason the first was also sent is that it wasn't applied when you
did the second send, and the new patch depends on it. Thus the second
patch can't be applied to the repo without also applying the first.

darcs doesn't know if the first patch is sitting in a queue waiting to
be applied, has been rejected, was sent to someone else, if the mail got
lost, etc.


Thanks
Ian

From ijones at syntaxpolice.org  Wed Jan 17 11:44:25 2007
From: ijones at syntaxpolice.org (Isaac Jones)
Date: Wed Jan 17 11:40:07 2007
Subject: [Conal Elliott] Re: getting cabal to pass more info to haddock
Message-ID: <83vej5fvrq.fsf@bishop.syntaxpolice.org>

An embedded message was scrubbed...
From: "Conal Elliott" <conal@conal.net>
Subject: Re: getting cabal to pass more info to haddock
Date: Wed, 17 Jan 2007 01:59:40 -0800
Size: 12920
Url: http://www.haskell.org/pipermail/cabal-devel/attachments/20070117/588032c1/attachment.eml
From ijones at syntaxpolice.org  Wed Jan 17 11:55:39 2007
From: ijones at syntaxpolice.org (Isaac Jones)
Date: Wed Jan 17 11:51:24 2007
Subject: [Conal Elliott] Re: getting cabal to pass more info to haddock
In-Reply-To: <83vej5fvrq.fsf@bishop.syntaxpolice.org> (Isaac Jones's message
	of "Wed, 17 Jan 2007 08:44:25 -0800")
References: <83vej5fvrq.fsf@bishop.syntaxpolice.org>
Message-ID: <837ivlfv90.fsf@bishop.syntaxpolice.org>

Hi Conel.  Thanks for this!  It sounds like the ideas from your
makefile could be used for Hackage for generating nice Haddock :)

There is a general meachanism for adding --foo-args for each Program
that cabal knows about; can you use this meachanism to add --foo-arg
as well, instead of special-casing for haddock?

If you do that, can you make the help output not suck?  Currently it
does something like this:

           --ar-args=ARGS                  give the args to ar
           --haddock-args=ARGS             give the args to haddock
           --ld-args=ARGS                  give the args to ld
           --pfesetup-args=ARGS            give the args to pfesetup
           --ranlib-args=ARGS              give the args to ranlib
           --runghc-args=ARGS              give the args to runghc
           --runhugs-args=ARGS             give the args to runhugs
           --tar-args=ARGS                 give the args to tar

it would be nice to concerve lines with sometthing like this:

--ar-arg=ARG       --ar-args=ARGS          give the arg or args to ar
--haddock-arg=ARG  --haddock-args=ARGS     give the arg or args to haddock
etc

The patch you sent seemed like an empty file to me.  Maybe I'm just
being nihilistic ;)

peace,

  isaac
From bringert at cs.chalmers.se  Thu Jan 18 08:41:05 2007
From: bringert at cs.chalmers.se (=?ISO-8859-1?Q?Bj=F6rn_Bringert?=)
Date: Thu Jan 18 08:36:44 2007
Subject: Hackage plan
In-Reply-To: <45ADF8D3.8030706@microsoft.com>
References: <45ACA2BF.3020508@microsoft.com>	<838xg2jlnb.fsf@bishop.syntaxpolice.org>
	<45ADF8D3.8030706@microsoft.com>
Message-ID: <45AF78F1.1070703@cs.chalmers.se>

Simon Marlow wrote:
> Isaac Jones wrote:
>> I think that, as far as Hackage (not cabal-install) is concerned, the
>> main usibility points are:
>>
>> 1) getting more packages into it
>> 2) making sure that all the packages build together, and
>> 3) searching
> 
> Ah yes, there was the idea of freezing a collection of packages that 
> build together too.

One related problem is that .cabal files don't allow you to describe the 
dependencies well enough. For example, many packages currently in 
Hackage have fps as a dependency. This is no good with base 2.0, which 
includes what used to be fps. But removing the fps dep will break 
building with base 1.0 + fps.

Some possible solutions:

- Allow boolean expressions not only of versions, but of packages as 
well. E.g.: Build-depends: base >= 2.0 || (base < 2.0 && fps >= 0.7)

- Have one Hackage repository for each Haskell implementation version, 
where the dependencies make sense together.

- Configurations?

/Bj?rn


From igloo at earth.li  Thu Jan 18 19:19:11 2007
From: igloo at earth.li (Ian Lynagh)
Date: Thu Jan 18 19:14:50 2007
Subject: Hackage plan
In-Reply-To: <45AF78F1.1070703@cs.chalmers.se>
References: <45ACA2BF.3020508@microsoft.com>
	<838xg2jlnb.fsf@bishop.syntaxpolice.org>
	<45ADF8D3.8030706@microsoft.com> <45AF78F1.1070703@cs.chalmers.se>
Message-ID: <20070119001911.GA30666@matrix.chaos.earth.li>

On Thu, Jan 18, 2007 at 02:41:05PM +0100, Bj?rn Bringert wrote:
> 
> One related problem is that .cabal files don't allow you to describe the 
> dependencies well enough.
> 
> - Configurations?

This is what configurations are designed for. Until we have them I think
the best thing is to have the packages in hackage work with the current
releases (I think ghc and hugs have pretty much the same libraries; I'm
not sure about nhc/yhc/jhc/... off the top of my head).

Hopefully before we have an incompatible new hugs/ghc release we'll have
a Cabal with configurations.


Thanks
Ian

From conal at conal.net  Fri Jan 19 20:18:07 2007
From: conal at conal.net (Conal Elliott)
Date: Fri Jan 19 20:13:41 2007
Subject: [Conal Elliott] Re: getting cabal to pass more info to haddock
In-Reply-To: <837ivlfv90.fsf@bishop.syntaxpolice.org>
References: <83vej5fvrq.fsf@bishop.syntaxpolice.org>
	<837ivlfv90.fsf@bishop.syntaxpolice.org>
Message-ID: <ea8ae9fb0701191718t717ed63i1142586a2290b5d2@mail.gmail.com>

Hi Isaac.  Now I see why the patch file was empty.  And after some
head-scratching about your note below, I'm glad the patch was empty.  I
hadn't noticed the --xxx-args flags for configure, and instead added a new
haddock flag.  Giving a flag to configure makes a lot more sense.

So now I have just a new pair of flags enable-use-packages &
disable-use-packages, which control whether haddock gets
automatically-generated --use-package flags.

My makefile are now performing this sort of incantation:

./setup configure --disable-use-packages --haddock-args="\
  --read-interface=
http://haskell.org/ghc/docs/latest/html/libraries/base,c:/ghc/ghc-6.6/doc/html/libraries/base/base.haddock\
  --read-interface=
http://haskell.org/ghc/docs/latest/html/libraries/mtl,c:/ghc/ghc-6.6/doc/html/libraries/mtl/mtl.haddock\
  "

The only problem is --haddock-args ends up turning my forward slashes into
backslashes, so all of the web links are broken.

Any advice?

   - Conal

On 1/17/07, Isaac Jones <ijones@syntaxpolice.org > wrote:
>
> Hi Conel.  Thanks for this!  It sounds like the ideas from your
> makefile could be used for Hackage for generating nice Haddock :)
>
> There is a general meachanism for adding --foo-args for each Program
> that cabal knows about; can you use this meachanism to add --foo-arg
> as well, instead of special-casing for haddock?
>
> If you do that, can you make the help output not suck?  Currently it
> does something like this:
>
>            --ar-args=ARGS                  give the args to ar
>            --haddock-args=ARGS             give the args to haddock
>            --ld-args=ARGS                  give the args to ld
>            --pfesetup-args=ARGS            give the args to pfesetup
>            --ranlib-args=ARGS              give the args to ranlib
>            --runghc-args=ARGS              give the args to runghc
>            --runhugs-args=ARGS             give the args to runhugs
>            --tar-args=ARGS                 give the args to tar
>
> it would be nice to concerve lines with sometthing like this:
>
> --ar-arg=ARG       --ar-args=ARGS          give the arg or args to ar
> --haddock-arg=ARG  --haddock-args=ARGS     give the arg or args to haddock
> etc
>
> The patch you sent seemed like an empty file to me.  Maybe I'm just
> being nihilistic ;)
>
> peace,
>
>   isaac
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/cabal-devel/attachments/20070119/e502b897/attachment.htm
From duncan.coutts at worc.ox.ac.uk  Mon Jan 22 13:47:48 2007
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Mon Jan 22 13:54:16 2007
Subject: debugging support - multidimensional package selection -
	excursion
In-Reply-To: <20070106120522.GB21452@gmx.de>
References: <20070106120522.GB21452@gmx.de>
Message-ID: <1169491668.8350.128.camel@localhost>

On Sat, 2007-01-06 at 13:05 +0100, Marc Weber wrote:

> This leads me to the question: Is it enough to identify a package by
> (name/id) and version?
> 
> I think a more dimensional way would be useful

> Any comments? Is this all nonsense ?

For some related work you might want to look at Nix:

http://www.cs.uu.nl/~eelco/pubs/

in particular it address the issue of identifying and separating builds
based on multiple variables (and managing the deps).

Duncan

From conal at conal.net  Mon Jan 22 21:11:52 2007
From: conal at conal.net (Conal Elliott)
Date: Mon Jan 22 21:07:16 2007
Subject: cabal-make almost ready
Message-ID: <ea8ae9fb0701221811w60789d40pbe16dc80715440ac@mail.gmail.com>

I've been working on some haddock-related Cabal tweaks and a "make" include
file called "cabal-make", which manages syntax coloring (vis hscolour) with
links from the haddock docs, web-based links to other libraries, and
wiki-based user comments.  It's ready to release for others' use except for
one problem (as mentioned below).  The --haddock-args flag ends up turning
my forward slashes into backslashes (on my WinXP machine), so all of the web
links are broken.  I'd appreciate suggestions about this problem.

You can find an example doc generated by cabal-make (a previous
implementation that didn't quite fit cabal) at
http://darcs.haskell.org/packages/TV/doc/html/Interface-TV-Output.html .
Suggestions welcome.

- Conal

---------- Forwarded message ----------
From: Conal Elliott <conal@conal.net>
Date: Jan 19, 2007 5:18 PM
Subject: Re: [Conal Elliott] Re: getting cabal to pass more info to haddock
To: Isaac Jones <ijones@syntaxpolice.org>
Cc: cabal-devel <cabal-devel@haskell.org>

Hi Isaac.  Now I see why the patch file was empty.  And after some
head-scratching about your note below, I'm glad the patch was empty.  I
hadn't noticed the --xxx-args flags for configure, and instead added a new
haddock flag.  Giving a flag to configure makes a lot more sense.

So now I have just a new pair of flags enable-use-packages &
disable-use-packages, which control whether haddock gets
automatically-generated --use-package flags.

My makefile are now performing this sort of incantation:

./setup configure --disable-use-packages --haddock-args="\
  --read-interface=http://haskell.org/ghc/docs/latest/html/libraries/base,c:/ghc/ghc-6.6/doc/html/libraries/base/base.haddock
\
  --read-interface=http://haskell.org/ghc/docs/latest/html/libraries/mtl,c:/ghc/ghc-6.6/doc/html/libraries/mtl/mtl.haddock\
  "

The only problem is --haddock-args ends up turning my forward slashes into
backslashes, so all of the web links are broken.

Any advice?

   - Conal

On 1/17/07, Isaac Jones <ijones@syntaxpolice.org > wrote:
>
> Hi Conel.  Thanks for this!  It sounds like the ideas from your
> makefile could be used for Hackage for generating nice Haddock :)
>
> There is a general meachanism for adding --foo-args for each Program
> that cabal knows about; can you use this meachanism to add --foo-arg
> as well, instead of special-casing for haddock?
>
> If you do that, can you make the help output not suck?  Currently it
> does something like this:
>
>            --ar-args=ARGS                  give the args to ar
>            --haddock-args=ARGS             give the args to haddock
>            --ld-args=ARGS                  give the args to ld
>            --pfesetup-args=ARGS            give the args to pfesetup
>            --ranlib-args=ARGS              give the args to ranlib
>            --runghc-args=ARGS              give the args to runghc
>            --runhugs-args=ARGS             give the args to runhugs
>            --tar-args=ARGS                 give the args to tar
>
> it would be nice to concerve lines with sometthing like this:
>
> --ar-arg=ARG       --ar-args=ARGS          give the arg or args to ar
> --haddock-arg=ARG  --haddock-args=ARGS     give the arg or args to haddock
> etc
>
> The patch you sent seemed like an empty file to me.  Maybe I'm just
> being nihilistic ;)
>
> peace,
>
>   isaac
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/cabal-devel/attachments/20070122/f0124a79/attachment.htm
From bos at serpentine.com  Thu Jan 25 01:37:09 2007
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Thu Jan 25 01:32:26 2007
Subject: Cabal bug, times two and a half
Message-ID: <45B85015.50509@serpentine.com>

I tried reporting a Cabal bug via Trac, but I can't log in as 
guest/haskell.  Alas.

The bug is that "runhaskell Setup.hs --enable-library-profiling" doesn't 
imply -auto-all with ghc, so the profiled library contains only manual 
cost centres - in other words, it never shows up in profile output.

The second bug is that the only way I can find to override or add 
compiler flags is to edit a .cabal file by hand.  This makes it scarily 
easy to capture unintended flags when committing changes :-(

	<b
From conal at conal.net  Thu Jan 25 01:51:36 2007
From: conal at conal.net (Conal Elliott)
Date: Thu Jan 25 01:46:52 2007
Subject: cabal-make almost ready
In-Reply-To: <ea8ae9fb0701221811w60789d40pbe16dc80715440ac@mail.gmail.com>
References: <ea8ae9fb0701221811w60789d40pbe16dc80715440ac@mail.gmail.com>
Message-ID: <ea8ae9fb0701242251n367494fhe5fa17e84434560c@mail.gmail.com>

Do forward slashes get turned into backslashes for xxxx-args arguments in
Windows?  Could someone point me to the code that does it?  I could add a
setup flag that disables the translation, or maybe detect the "http://" and
just preserve what looks to be URLs.

BTW, cabal-make now has a target that auto-subscribes to all wiki talk pages
generated for a project.

  - Conal

On 1/22/07, Conal Elliott <conal@conal.net> wrote:
>
> I've been working on some haddock-related Cabal tweaks and a "make"
> include file called "cabal-make", which manages syntax coloring (vis
> hscolour) with links from the haddock docs, web-based links to other
> libraries, and wiki-based user comments.  It's ready to release for others'
> use except for one problem (as mentioned below).  The --haddock-args flag
> ends up turning my forward slashes into backslashes (on my WinXP machine),
> so all of the web links are broken.  I'd appreciate suggestions about this
> problem.
>
> You can find an example doc generated by cabal-make (a previous
> implementation that didn't quite fit cabal) at http://darcs.haskell.org/packages/TV/doc/html/Interface-TV-Output.html
> .  Suggestions welcome.
>
> - Conal
>
> ---------- Forwarded message ----------
> From: Conal Elliott <conal@conal.net >
> Date: Jan 19, 2007 5:18 PM
> Subject: Re: [Conal Elliott] Re: getting cabal to pass more info to
> haddock
> To: Isaac Jones <ijones@syntaxpolice.org>
> Cc: cabal-devel < cabal-devel@haskell.org>
>
> Hi Isaac.  Now I see why the patch file was empty.  And after some
> head-scratching about your note below, I'm glad the patch was empty.  I
> hadn't noticed the --xxx-args flags for configure, and instead added a new
> haddock flag.  Giving a flag to configure makes a lot more sense.
>
> So now I have just a new pair of flags enable-use-packages &
> disable-use-packages, which control whether haddock gets
> automatically-generated --use-package flags.
>
> My makefile are now performing this sort of incantation:
>
> ./setup configure --disable-use-packages --haddock-args="\
>   --read-interface=http://haskell.org/ghc/docs/latest/html/libraries/base,c:/ghc/ghc-6.6/doc/html/libraries/base/base.haddock
> \
>   --read-interface=http://haskell.org/ghc/docs/latest/html/libraries/mtl,c:/ghc/ghc-6.6/doc/html/libraries/mtl/mtl.haddock\
>   "
>
> The only problem is --haddock-args ends up turning my forward slashes into
> backslashes, so all of the web links are broken.
>
> Any advice?
>
>    - Conal
>
> On 1/17/07, Isaac Jones <ijones@syntaxpolice.org > wrote:
> >
> > Hi Conel.  Thanks for this!  It sounds like the ideas from your
> > makefile could be used for Hackage for generating nice Haddock :)
> >
> > There is a general meachanism for adding --foo-args for each Program
> > that cabal knows about; can you use this meachanism to add --foo-arg
> > as well, instead of special-casing for haddock?
> >
> > If you do that, can you make the help output not suck?  Currently it
> > does something like this:
> >
> >            --ar-args=ARGS                  give the args to ar
> >            --haddock-args=ARGS             give the args to haddock
> >            --ld-args=ARGS                  give the args to ld
> >            --pfesetup-args=ARGS            give the args to pfesetup
> >            --ranlib-args=ARGS              give the args to ranlib
> >            --runghc-args=ARGS              give the args to runghc
> >            --runhugs-args=ARGS             give the args to runhugs
> >            --tar-args=ARGS                 give the args to tar
> >
> > it would be nice to concerve lines with sometthing like this:
> >
> > --ar-arg=ARG       --ar-args=ARGS          give the arg or args to ar
> > --haddock-arg=ARG  --haddock-args=ARGS     give the arg or args to
> > haddock
> > etc
> >
> > The patch you sent seemed like an empty file to me.  Maybe I'm just
> > being nihilistic ;)
> >
> > peace,
> >
> >   isaac
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/cabal-devel/attachments/20070124/aed5cb50/attachment-0001.htm
From simonmarhaskell at gmail.com  Thu Jan 25 05:10:24 2007
From: simonmarhaskell at gmail.com (Simon Marlow)
Date: Thu Jan 25 05:05:42 2007
Subject: Cabal bug, times two and a half
In-Reply-To: <45B85015.50509@serpentine.com>
References: <45B85015.50509@serpentine.com>
Message-ID: <45B88210.4030402@gmail.com>

Bryan O'Sullivan wrote:
> I tried reporting a Cabal bug via Trac, but I can't log in as 
> guest/haskell.  Alas.

The password is "haskell'" (note the final apostrophe).  Isaac: maybe we should 
use a simpler password?

> The bug is that "runhaskell Setup.hs --enable-library-profiling" doesn't 
> imply -auto-all with ghc, so the profiled library contains only manual 
> cost centres - in other words, it never shows up in profile output.

Not adding -auto-all is the right default; the intended usage is for building a 
profiled version of the library so that a user can profile their own application 
against it, not to profile the library itself.

If you want to profile the library, add "ghc-options: -auto-all" to the .cabal 
file.  When we have configurations you'll be able to make this optional, but for 
now just add it by hand to .cabal (and don't forget to remove it later).

> The second bug is that the only way I can find to override or add 
> compiler flags is to edit a .cabal file by hand.  This makes it scarily 
> easy to capture unintended flags when committing changes :-(

er. what I said above :)  The technology that fixes this long-term shortcoming 
is designed (several times!) but sadly not implemented yet.

If you use the Emacs darcsum mode, it's scarily easy to avoid committing things 
that you don't want to.  darcsum is to command-line darcs as vi is to ed.

Cheers,
	Simon
From dons at cse.unsw.edu.au  Thu Jan 25 05:35:05 2007
From: dons at cse.unsw.edu.au (Donald Bruce Stewart)
Date: Thu Jan 25 05:30:26 2007
Subject: Cabal bug, times two and a half
In-Reply-To: <45B88210.4030402@gmail.com>
References: <45B85015.50509@serpentine.com> <45B88210.4030402@gmail.com>
Message-ID: <20070125103505.GA26855@cse.unsw.EDU.AU>

simonmarhaskell:
> Bryan O'Sullivan wrote:
> >I tried reporting a Cabal bug via Trac, but I can't log in as 
> >guest/haskell.  Alas.
> 
> The password is "haskell'" (note the final apostrophe).  Isaac: maybe we 
> should use a simpler password?
> 
> >The bug is that "runhaskell Setup.hs --enable-library-profiling" doesn't 
> >imply -auto-all with ghc, so the profiled library contains only manual 
> >cost centres - in other words, it never shows up in profile output.
> 
> Not adding -auto-all is the right default; the intended usage is for 
> building a profiled version of the library so that a user can profile their 
> own application against it, not to profile the library itself.
> 
> If you want to profile the library, add "ghc-options: -auto-all" to the 
> .cabal file.  When we have configurations you'll be able to make this 
> optional, but for now just add it by hand to .cabal (and don't forget to 
> remove it later).

Should -auto-all be used for --enable-executable-profiling though?
I think its missing there too, which seems wrong?

-- Don
From duncan.coutts at worc.ox.ac.uk  Thu Jan 25 06:29:07 2007
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Thu Jan 25 06:35:16 2007
Subject: cabal-make almost ready
In-Reply-To: <ea8ae9fb0701242251n367494fhe5fa17e84434560c@mail.gmail.com>
References: <ea8ae9fb0701221811w60789d40pbe16dc80715440ac@mail.gmail.com>
	<ea8ae9fb0701242251n367494fhe5fa17e84434560c@mail.gmail.com>
Message-ID: <1169724547.29253.96.camel@localhost>

On Wed, 2007-01-24 at 22:51 -0800, Conal Elliott wrote:
> Do forward slashes get turned into backslashes for xxxx-args arguments
> in Windows?

Are you using a shell like Mingw's MSYS? If so it does do that kind of
translation. If you're getting that behaviour when using an ordinary
windows command prompt (cmd.exe) then it's a cabal issue.

Duncan

From duncan.coutts at worc.ox.ac.uk  Thu Jan 25 06:30:46 2007
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Thu Jan 25 06:36:55 2007
Subject: Cabal bug, times two and a half
In-Reply-To: <20070125103505.GA26855@cse.unsw.EDU.AU>
References: <45B85015.50509@serpentine.com> <45B88210.4030402@gmail.com>
	<20070125103505.GA26855@cse.unsw.EDU.AU>
Message-ID: <1169724646.29253.98.camel@localhost