haskell / cabal Goto Github PK

(Imported from Trac #7, reported by @SyntaxPolice on 2005-10-31)

this should be done w/ the Distribution.Program interface, and is closely related to #5 and #6.

(Imported from Trac #28, reported by krasimir on 2005-12-08)

The shipment will allow to distribute multiple Cabal packages in one distribution. See hawiki pages:

• [http://www.haskell.org/hawiki/Cabal_2fAggregatePackages](http://www.haskell.org/hawiki/Cabal_2fAggregatePackages)
• [http://www.haskell.org/hawiki/Cabal_2fMultiPackageDistributables](http://www.haskell.org/hawiki/Cabal_2fMultiPackageDistributables)

(Imported from Trac #4, reported by @SyntaxPolice on 2005-10-31)

Somehow it would be nice to identify the version of Cabal that the .cabal file conforms to

(Imported from Trac #41, reported by @SyntaxPolice on 2006-01-09)

See [source:Distribution/Simple/SrcDist.hs]:132

(Imported from Trac #22, reported by anonymous on 2005-11-15)

From Bryn Keller

I took a better look at the GNUMakefile for Cabal-1.1.1 and realized it
was a complete red herring - best ignored altogether under Windows!
Doing the regular cabal dance worked just fine and I now have
Cabal-1.1.1 installed.
As for cabal-get, I ran into a couple of problems - first of all,
"./setup" fails because the shell that runs it (even if invoked under
Cygwin) is cmd.exe, not bash. Second, the sudo command doesn't exist
even in Cygwin. I'm attaching patches for these issues. Finally, the
install script fails because GNUpgp package has an error in its cabal
file - it specifies "hs-source-dirs: src," but it should be
"hs-source-dir", not "hs-source-dirs", and the source is not actually in
a "src" dir at all. Removing that line from the .cabal file fixed that
problem.
Also, I keep getting warnings from ghc like:
ghc: unknown package: Cabal-1.0
though this doesn't actually seem to cause a problem so far. Not sure
why it's looking for Cabal-1.0 when I already have Cabal-1.1.1. (I had
to unregister Cabal-1.0 to avoid other errors).  Interestingly, many
packages wouldn't compile until I removed Crypto-2.0.2 from my system.
I would have expected that different version could coexist... oh well.
More seriously, I get this compile error:
Compiling Network.Hackage.CabalGet.Install (
./Network/Hackage/CabalGet/Install.
hs, dist\build\./Network/Hackage/CabalGet/Install.o )
./Network/Hackage/CabalGet/Install.hs:118:45: Not in scope: `installHandler'
./Network/Hackage/CabalGet/Install.hs:118:60: Not in scope: `keyboardSignal'
./Network/Hackage/CabalGet/Install.hs:118:76:
   Not in scope: data constructor `Catch'
./Network/Hackage/CabalGet/Install.hs:120:31: Not in scope: `installHandler'
./Network/Hackage/CabalGet/Install.hs:120:46: Not in scope: `keyboardSignal'
Thanks,
Bryn

(Imported from Trac #15, reported by @SyntaxPolice on 2005-10-31)

Implement inter-module dependency analysis. This will improve a number of features, including:

• Obviate other-modules field
• Building DLLs?

(Imported from Trac #34, reported by @igfoo on 2005-12-11)

.o files may be generated by means outside of cabal, and there should be a way to list them in the .cabal file as being linked with the library.

(Imported from Trac #3, reported by anonymous on 2005-10-31)

These flags are not necessary, but could be useful as a workaround for platforms without ghci. Remove them? Maybe not.

(Imported from Trac #45, reported by @SyntaxPolice on 2006-01-09)

install the haddock interface, and fill in the location in haddock_interfaces. Similarly for the HTML, and haddock_html.

(Imported from Trac #47, reported by @SyntaxPolice on 2006-01-09)

A binary distribution.

(Imported from Trac #5, reported by @SyntaxPolice on 2005-10-31)

This is mostly done in current darcs version of Cabal-1.1.7.

grep for remaining uses of rawSystemExit / rawSystemPath.

(Imported from Trac #2, reported by @SyntaxPolice on 2005-10-31)

Move the bugs from the TODO list into this BTS.

(Imported from Trac #19, reported by @dcoutts on 2005-11-07)

Cabal should somehow support ghc's -split-objs feature for building libraries since it makes execuatables which link to them statically much smaller (eg the Gtk2Hs hello world program shrank by 90% after -split-objs support was added to the Gtk2Hs build system).

Currently, ghc Foo.hs -o Foo.o -split-objs flag tells ghc to instead of creating the Foo.o file it creates a directory Foo_split/ which will then contain many Foo_XXX.o files. Possibly several thousand .o files for a large module and when optimisation is turned on. This object file splitting obviously complicates the build procedure.

There are a number of ways this could supported in Cabal:

GHC could be improved so that --make and -split-objs work together ok. This would be good.

In the abcense of better GHC support it might be possible to use -split-objs with --make but it'd requre -no-link and then using a different link step from that which ghc --make uses:

1 . It requires several invocations of ar because there may be more .o files than will fit on one command line (eg Gtk2Hs's main libHSgtk.a file contains over 12,000 .o files when using -split-objs; GHC's libHSbase.a has a similar number).
2. It requires different ar flags. It must use 'q' rather than 'r' or things will go wrong for libs with multiple modules with the same name suffix, eg Foo1.Bar and Foo2.Bar would clash (because the .o file would have the same name, since ar ignores the paths).

However the implementation in Cabal would be different again if Cabal is moving to having seperate dep resolution rather than relying on GHC's --make feature. The points above about the use of ar still apply. GHC's own libs are built in this style at the moment, that is using -split-objs and without using --make. GHC's build system is a useful reference for the correct use of -split-objs. It uses xargs to help with the invocation of ar. Note however that it uses the wrong ar flags, though in ghc's case it doesn't matter since there are no modules with clashing file names.

(Imported from Trac #43, reported by @SyntaxPolice on 2006-01-09)

See the TODO in Hugs.hs:installHugs around line 209.

When we generate the runhugs command, we should not only use the options and language extensions for this package but also all those of packages that this executable depends on. This is because hugs has no notion of package, so we have to use the union of all flags/extensions and just prey that they are compatible.

(Imported from Trac #36, reported by chucky on 2006-01-06)

I believe I have found a bug. Consider the following code:

In TestPackage?.cabal:

Name:           TestPackage
Version:    0.0
Executable: test
Main-Is: Main.hs
Executable: test2
Main-Is: Main2.hs

In TestPackage?.buildinfo:

Executable: test
Buildable: True
Executable: test2
Buildable: True

In Setup.hs:

import Distribution.Simple
main = defaultMainWithHooks defaultUserHooks

When executing "runhaskell Setup.hs build" this code complains: "Setup.hs: Package TestPackage?-0.0 can't be built on this system." If you have only one executable in the packageinfo file, everything works as expected.

(Imported from Trac #40, reported by @SyntaxPolice on 2006-01-09)

What do other tools do for tar in windows?

(Imported from Trac #42, reported by @SyntaxPolice on 2006-01-09)

A pretty simple approach:

The package database is a list, mapping package names to directories.
Maybe the gentoo folks and others would be happier if it's a
directory where each file name is a package name and the content of
that file is a directory to find the source for this package.

If we go the "don't alter hugs" route, we'd need a wrapper around hugs
(maybe cabal) to read this file and add the -i flags to the hugs
command-line.

So this could be implemented outside of hugs, with just cabal and
hugs-pkg, then we could include a concept of a package database in the
cabal interface to make toast / gentoo happy. In fact, we
could do all that in Cabal without a hugs-pkg.

Of course, it would be nice if someone could say ":package foo" on the
Hugs command-line, but that's not completely necessary. We could punt
on that until we get more clear about the role of packages in the
language.

When implementing this, be sure to add

1. register step to cabal (register in hugs a little bit of something)
2. hugs-pkg as a package tool
3. command-line args to hugs or hugsWrap relating to the packages

Problems with not having hugs-pkg

1. no way to tell hugs to turn packages on / off
2. register / unregister don't make much sense
3. no way to install into a non-standard location and expect hugs to find the package

(Imported from Trac #48, reported by @dcoutts on 2006-01-16)

To properly support c2hs in Cabal we need a couple enhancements:

1. dependency resolution.
   Not only do the .hs files depend on the .chs files but .chs files can depend on other .chs files (or strictly speaking on their corresponding .chi files).

This is because c2hs supports its own module import mechanism to get information about bindings defined in one module to be used in other modules.

From the c2hs manual:

If the compiled binding module contains import hooks, C->Haskell needs to
find the .chi (C->Haskell interface files) produced while compiling the
corresponding binding modules. By default, they will be searched for in
the current working directory. If they are located elsewhere, the
--include=INCLUDE option has to be used to indicate the location, where
INCLUDE is a colon-separated list of directories. Multiple such options
are admissible. Paths specified later are searched first.

1. The .chi files need to be installed

If one Cabal package uses .chs files then another package that wants to import that module into another .chs module using c2hs's import mechanism will need access to the .chi file of the imported module. This is basically the same as how ghc needs the .hi file of imported modules.

One difference is that .chi modules are transitive (unlike ghc's .hi files) so only the .chi files corresponding to exposed modules need to be installed (where as for ghc every .hi file needs to be installed).

Both of these enhancements are essential to be able to package Gtk2Hs using Cabal. Gtk2Hs has many .chs modules and with dependencies between them, including many dependencies between .chs modules in different packages. For example all of the Gtk+ extension packages (OpenGL, SourceView, Glade, Mozilla embeding widget) import type definitions from .chs modules in the base gtk & glib packages.

(Imported from Trac #39, reported by @SyntaxPolice on 2006-01-09)

If there's a flag, --include-preprocessed-sources (or something better) run the preprocessing phase and include both the unpreprocessed and the preprocessed sources in the source tarball?

But really, there are two kinds of preprocessors, as Ross points out. The kind that produce OS-independent code, and the kind that produce OS-dependent code. Perhaps this concept should be added to the
PreProcessor? type, and a we could have two flags to sdist:

--include-standalone-preprocessed-sources

Which would generate the OS-independent sources from tools like Alex and Happy...

--include-all-preprocessed-sources

Which just includes all of the preprocessed sources as above.

A downside to this is in how it interacts with another proposal to add tool dependencies. If a package tool-depends on "alex", and then a source tarball is created with --include-standalone-preprocessed-sources, then it actually no longer tool-depends on alex, so we should regenerate the .cabal file. I guess that's no big deal.

(Imported from Trac #25, reported by @SyntaxPolice on 2005-11-29)

should cabal-install be a part of the cabal release, or separate? if it's part of cabal, it probably won't come w/ ghc.

We need to release it in a release-candidate so that people can try it out, so we can decide if it goes into 1.2.

(Imported from Trac #23, reported by @kosmikus on 2005-11-23)

Three hooks per phase is nice for end user, IMO. Decided to clean up hooks instead of make this modification.

Why is it necessary to have three hooks per phase. The ability to replace the phase
itself should be enough, shouldn't it?

If I want to do something after configuration, I can say something like

myHooks = defaultUserHooks { confHook = myConf }
myConf pd cf = do lbi <\- confHook defaultUserHooks
                  myPostConf pd cf lbi

Seems simpler to me than to have additional pre- and post-hooks for each phase.

(Imported from Trac #46, reported by @SyntaxPolice on 2006-01-09)

FIX markings should probably be entered into this system and cross-referenced.

(Imported from Trac #37, reported by @SyntaxPolice on 2006-01-07)

from Malcolm:

cpphs has no pre-defined macros, and no predefined include paths.
If you want it to pretend to be ghc -cpp, you need to add arguments like

-DGLASGOW_HASKELL=604 -I/usr/local/lib/ghc-6.4.1/includes

explicitly. (More generally, you might want to record such arguments
in a little wrapper script that calls cpphs.)

(Imported from Trac #17, reported by @SyntaxPolice on 2005-10-31)

This relates to building dependency analysis. #15*.

Cabal does not handle dependencies for HSC2HS correctly. For example,
if Foo.hsc has

#include "x.h"

then Foo.hs should get regenerated whenever x.h is modified. However,
Cabal only regenerates Foo.hs when Foo.hsc has been modified.

(Imported from Trac #38, reported by @SyntaxPolice on 2006-01-09)

Currently, cabal can either register a package or generate a script to register the package later. Unfortunitely, gentoo would like to register the package themselves, but we don't generate a package.conf file for them.

A possible solution is to generate a package.conf file at a given location. The problem is that this breaks abstraction from ghc-pkg. Probably will do it anyway.

(Imported from Trac #18, reported by @SyntaxPolice on 2005-10-31)

Trac can work with darcs. Install this version and point it at the cabal darcs repo.

(Imported from Trac #30, reported by @SyntaxPolice on 2005-12-10)

Right now, cabal-install will only run runghc or runhugs on the Setup script. This precludes using nhc or building the script w/ ghc.

Not all versions of ghc have good runghc programs.

(Imported from Trac #27, reported by @simonmar on 2005-12-08)

Latest proposal is here. Below might be out of date.

The idea is to add support for

• optional dependencies
• optional stanzas in the package description

• command-line options to configure, eg. --enable-debug
• properties of the environment (eg. GHC version, platform)
• environment variables
• combinations of the above

• allow different configurations to go into different build trees so they don't conflict w/ each-other?

package: foo
build-depends: base>=1.0
configuration: debug
ghc-options: -DDEBUG -O0 -Wall
configuration: !debug
ghc-options: -O
configuration: OS=windows
build-depends: Win32
configuration: !OS=windows
build-depends: unix
configuration: COMPILER=ghc
build-depends: fps

 config0 ::= label
           | label=value
           | (config)
 config  ::= !config0
           | config0 | config
           | config, config

A label expression can be made true by either adding --enable-label on the configure command line, or by setting the ENABLE_label environment variable.

A 'label=value' expression can be set by either --with-label=value on the configure command line, or by setting label=value in the environment.

Configure --help will list the available --enable and --with options by examining the package description.

We might need a --disable-environment setting to disable taking settings from the environment, so that automatic packaging systems can be made more robust in the face of arbitrary environment settings.

(Imported from Trac #13, reported by @SyntaxPolice on 2005-10-31)

Allow preprocessor chaining so that a file can be preprocessed by more than one tool.

(Imported from Trac #11, reported by @SyntaxPolice on 2005-10-31)

We need to make this more explicit somewhere so that it's clear what might break in the future. Most of this is in the [source:Distribution/Simple.hs Simple module]. The first pass is at StableInterfaces.

(Imported from Trac #29, reported by @SyntaxPolice on 2005-12-10)

This will require some refactoring, since we'll have to unpack all of the packages on the command-line first, then read their .cabal files to get the dependencies.

Also look at what's installed and whether or not all dependencies are met. cabal-get implements this already; should be refactored to move this code here, and cabal-get should call cabal-install.

(Imported from Trac #14, reported by @SyntaxPolice on 2005-10-31)

It is not clear how to build an executable whose Main module is
preprocessed. The following does not work:
Executable: Foo
Main-is: Main.hsc

(Imported from Trac #6, reported by @SyntaxPolice on 2005-10-31)

Done in current darcs version of Cabal-1.1.7.

(Imported from Trac #20, reported by @SyntaxPolice on 2005-11-12)

Test suite has 13 failures. Probably mostlyi because of bindir / libdir movement.

(Imported from Trac #10, reported by @SyntaxPolice on 2005-10-31)

(Imported from Trac #31, reported by @SyntaxPolice on 2005-12-11)

Possible, but I'm not sure it's desirable.

Add a field to .cabal, something like:
generate-cabal-info: true

and if that flag is set, output CabalInfo?.hs and add it to ExtraModules? for that stanza. This will contain PackageDescription? and LocalBuildInfo?.

Perhaps also add dependencies and versions here.

(Imported from Trac #12, reported by @SyntaxPolice on 2005-10-31)

(Imported from Trac #8, reported by @SyntaxPolice on 2005-10-31)

The current HEAD is probably broken for GHC 6.2 because we don't depend on unix. This has been causing problems for other tools, so we got rid of the dependency on utils.

(Imported from Trac #21, reported by anonymous on 2005-11-13)

A patch is attached, but it's out of date, I think. It needs to also work on executables. Also, we need to check that it works on lhs files, and add a test case.

(Imported from Trac #24, reported by @jgoerzen on 2005-11-28)

Cabal should not attempt to do anything relating to GHCI on archs that don't support it. It shouldn't try to build ghci libs, and it shouldn't pass --auto-ghci-libs to ghc-pkg.

More information here:

https://sourceforge.net/tracker/?func=detail&atid=108032&aid=1364839&group_id=8032

(Imported from Trac #35, reported by dastapov on 2005-12-16)

In order to use cabal-get one has to know which packages are available to install.
It would be nice if list of packages could be obtained by cabal-get itself, without need to go
see hackage.haskell.org

(Imported from Trac #26, reported by @SyntaxPolice on 2005-12-06)

@igfoo's idea. rather than making people use ghc-options: threaded, list it as an extension. Then cabal can give an error for Hugs if the program won't work there?

(Imported from Trac #9, reported by @SyntaxPolice on 2005-10-31)

Currently, building the setup file will pick up the version in Distribution, which is often what we want, but not necessarily always.

We should probably move the source to a subdirectory, but this may cause complications in keeping in sync w/ CVS. Also will have to fix the makefile.

(Imported from Trac #16, reported by @SyntaxPolice on 2005-10-31)

Re-link only when necessary. This relates to building dependency analysis. #15.

(Imported from Trac #1, reported by @SyntaxPolice on 2005-10-31)

Enter each of these bugs into this BTS.

(Imported from Trac #50, reported by @SyntaxPolice on 2006-01-20)

Email from John Meacham below. Another possibility is to make it rather like a hook.

I'd rather work on making a general compiler framework for it so that
jhc can just drop a file describing its interface in
/usr/share/lib/cabal/compilers/jhc.cabal-compiler or something and
cabal will automatically be able to use it. Ideally, one would not have
to upgrade their cabal just because they install (or write) a new
haskell compiler. I think all compilers conform to one of

hmake-like: ghc --make, jhc, nhc + hmake
interpreter-like: hugs
gcc-like: ghc, nhc98

so a compiler declaration file would not have to be much more
complicated than a string telling it how to invoke the compiler and a
mapping of various extensions/cabal options -> compiler flags.

I'd also like to do something like this for preprocessors, which would
be a much simpler project so will probably do first.

(Imported from Trac #44, reported by @SyntaxPolice on 2006-01-09)

haddock should be passed the names of the interface files for the
dependent packages (gotten from haddock_interfaces field of the
dependent packages, query ghc-pkg).

(Imported from Trac #32, reported by @SyntaxPolice on 2005-12-11)

For each dependency, during configure time, we figure out the exact version we're using. We could put that on the CPP command line to make conditional compilation more convenient:

-DPACKAGE_FOO_VERSION=1.1

Are there any problems w/ this approach?

(Imported from Trac #49, reported by @SyntaxPolice on 2006-01-20)

from John Meacha

Cabal should ignore any field starting with 'x-'
as a user defined extension.

I'd like to use locally things like

x-publish-site: /home/john/public_html/...
x-darcs-repo: http://repetae.net/repos/jhc

or experimental things like
x-jhc-namespace: 0x220

without cabal getting huffy about unknown fields.

obviously any popular and generally useful ones would eventually be
standardized and the x- can be discarded.

this is a fairly standard convention among file formats and is used in
mime types too.

(Imported from Trac #33, reported by @igloo on 2005-12-11)

With "defaultMainWithHooks defaultUserHooks" clean is not removing config.log, config.status. Hmm, the dist/ directory doesn't seem to be being removed either.

Again with "defaultMainWithHooks defaultUserHooks", sdist doesn't copy configure.