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,
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
More information about the cabal-devel
mailing list