where more info? comments on previous posts

Marc Weber marco-oweber at gmx.de
Sat Jan 6 06:09:57 EST 2007

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,
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
	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
	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

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

	./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
	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
	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


[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

[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.

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

More information about the cabal-devel mailing list