Gregory & cabal-devel,
I like his suggestion about --register for applications. I've
attached a patch (which I can't push at the moment becuase I have no
internet.)
About the macports empty directories, that's a bit more strange. Is
there any way to instruct macports to NOT delete empty directories?
Alternately, it would be nice if ghc-pkg were a bit more
fault-tolerant. What does the --force flag do? Does it actually
create the directory?
peace,
isaac
New patches:
[don't return an error code just because there's no library to register
[EMAIL PROTECTED] {
hunk ./Distribution/Simple.hs 667
- else die "Package contains no library to register"
+ else setupMessage "Package contains no library to register:" pkg_descr
}
Context:
[Remove erroneous exports...
[EMAIL PROTECTED]
[Patch to fix "-ixyz" being overwritten by "-i" and to remove Cabal's dependency on the Cabal package.
[EMAIL PROTECTED]
[Separate build into "make build" and "make install"
[EMAIL PROTECTED]
[Fixups to get cabal-get into Cabal
[EMAIL PROTECTED]
[Update Cabal with cabal-get
[EMAIL PROTECTED]
[Fix JHC command lines.
Einar Karttunen <ekarttun@cs.helsinki.fi>**20060427005922]
[document install-includes and register --inplace
Simon Marlow <[EMAIL PROTECTED]>**20060428130542]
[fix imports for Windows
[EMAIL PROTECTED]
[Better support for packages that need to install header files
Simon Marlow <[EMAIL PROTECTED]>**20060426140627
There's a new field for .cabal files:
install-includes: foo.h bar.h
This means the same as 'includes', except that the files named therein
will be installed into $libdir/include. 'includes' should only be
used for headers already installed on the system.
Directories listed in 'include-dirs' still turn into -I options for
hsc2hs, cpphs, and C compilations. However, for installation
purposes, relative directories in 'include-dirs' are now treated
differently from absolute directories:
- an absolute directory is copied to the include-dirs field
of the installed package config
- files names in install-includes are assumed to be found in
one of the *relative* directories listed in include-dirs
So the common pattern for providing a header file that you want to
be available everywhere including to via-C compilations against this
package:
include-dirs: myincludes
install-includes: foo.h
will install the header file myincludes/foo.h in
$libdir/include/foo.h.
]
[merge from base:
Simon Marlow <[EMAIL PROTECTED]>**20060426121408
Wed Apr 26 13:11:10 BST 2006 Simon Marlow <[EMAIL PROTECTED]>
* RequireOrder: do not collect unrecognised options after a non-opt
]
[pass unrecognised options before the command name to the command
Simon Marlow <[EMAIL PROTECTED]>**20060426121321
Previously, options before the command name other than --help were
just ignored, which is quite confusing behaviour. So now,
./setup --with-compiler=ghc-6.4.2 configure
works as you expect, instead of ignoring the --with-compiler option.
]
[First attempt at a cabal-setup command
Simon Marlow <[EMAIL PROTECTED]>**20060303162233
cabal-setup is a replacement for 'runhaskell Setup.hs'. It accepts
exactly the same commands. Additionally, the following new features
are provided:
* Setup.{hs,lhs} is optional. If omitted, cabal-setup behaves just
like Distribution.Simple.defaultMain.
* If the .cabal file contains a cabal-version field, then Setup.hs
is built using an appropriate version of Cabal. This might entail
creating Setup.hs if it doesn't exist.
* cabal-setup interprets the options --with-compiler and --with-hc-pkg
to determine the compiler used to compile Setup.hs.
Later, we could add support for building multiple packages in
dependency order, as per recent discussions on [EMAIL PROTECTED]
]
[add new modules
Ross Paterson <[EMAIL PROTECTED]>**20060425195548]
[Implement "setup register --inplace", and a few other minor things
Simon Marlow <[EMAIL PROTECTED]>**20060425144733
There are a few changes in this patch:
- New flag to register, --inplace. "setup register --inplace"
registers the package for use in the build tree, i.e. without
installing. It works with GHC only, currently.
- The parameters to RegisterCmd, UnregisterCmd and InstallCmd are a
legacy from before the time of hooks (or something) and don't
serve any purpose any more, AFAICT. So I removed them.
- I don't think "setup register" worked propertly before if
--user was given to configure. It does now.
- New flag to register: --with-hc-pkg (just the same as when
given to configure, but lets you override it at register-time)
]
[Refactoring only: separate compiler-specific simple build implementation
Simon Marlow <[EMAIL PROTECTED]>**20060425111957]
[get LocalBuildInfo from Distribution.LocalBuildInfo
Simon Marlow <[EMAIL PROTECTED]>**20060425111921]
[warning cleanup
Simon Marlow <[EMAIL PROTECTED]>**20060425102302]
[Distribution.Compat.FilePath should be hidden
Simon Marlow <[EMAIL PROTECTED]>**20060411141305
This also matches package.conf.in.
]
[Hide Distribution.GetOpt; it just re-exports System.Console.GetOpt anyway
Simon Marlow <[EMAIL PROTECTED]>**20060411141045
This also matches Cabal.cabal.
]
[GHC FFI flag should be -fffi not -ffi, the latter merely happens to work.
Duncan Coutts <[EMAIL PROTECTED]>**20060318022010]
[Make ghc-6.2 packages be exposed by default.
Duncan Coutts <[EMAIL PROTECTED]>**20060221135026
For ghc-6.4 when Cabal registers packages it exposes them by default.
However it does not do the same fo ghc-6.2. This change corrects the
discrepancy. This patch is already being used in Gentoo with Cabal 1.1.3.
]
[test case for buildinfo with multiple executables
[EMAIL PROTECTED]
[It is no longer necessary to run 'configure' before 'clean' or 'sdist', addressing http://haskell.galois.com/trac/hackage/ticket/12.
Nick Alexander <[EMAIL PROTECTED]>**20060404054127
In order to change this behaviour, it was necessary to modify the hook interface, specifically cleanHook, postClean, sDistHook, postSDist. They now take a Maybe LocalBuildInfo, since a LocalBuildInfo might not be available in .setup-config.
]
[windows patch from [EMAIL PROTECTED]
[EMAIL PROTECTED]
[oops, don't enable -split-objs by default
Simon Marlow <[EMAIL PROTECTED]>**20060314124358]
[export configDependency
Simon Marlow <[EMAIL PROTECTED]>**20060303155527]
[comment fix
Simon Marlow <[EMAIL PROTECTED]>**20060303155516]
[don't check cabal-version during parsing, it doesn't work
Simon Marlow <[EMAIL PROTECTED]>**20060303155500
because parsers are evaluated multiple times due to backtracking.
]
[no need to use a verbatim copy of System.Console.GetOpt, omit if possible
Simon Marlow <[EMAIL PROTECTED]>**20060303144025]
[Support for -split-objs with GHC
Simon Marlow <[EMAIL PROTECTED]>**20060302170907
New configure option: --enable-split-objs creates libraries using
-split-objs with GHC (current HEAD or later only, the configure checks
for version 6.5). Fixes ticket #19.
]
[Initial support for JHC
Einar Karttunen <ekarttun@cs.helsinki.fi>**20060206233543]
[added some fields to test suite for duncan's mods
[EMAIL PROTECTED]
[fixup PackageDescription test code
Duncan Coutts <[EMAIL PROTECTED]>**20060201183912
just ignore the extra ParseOk warnings field
]
[ignore "x-" extension fields without a warning
Duncan Coutts <[EMAIL PROTECTED]>**20060201183145]
[Make unknown fields a warning rather than an error
Duncan Coutts <[EMAIL PROTECTED]>**20060201182944
Add support for warnings to the ParseResult type. Change existing
warnings from using Debug.Trace to use this new warning support.
]
[fix conflict
Simon Marlow <[EMAIL PROTECTED]>**20060206095833]
[push and pull all
[EMAIL PROTECTED]
[combine GNUmakefile and Makefile
Simon Marlow <[EMAIL PROTECTED]>**20060206095400]
[now build Setup.lhs instead of using runghc on it. still uses runhugs.
[EMAIL PROTECTED]
[cabal-install uses defaultMain if it can't find Setup.lhs
[EMAIL PROTECTED]
[cleaned up suffix handler params to hooks
[EMAIL PROTECTED]
Summary if last few changes: I modified the hooks interface quite a
bit, again. There's good news and bad news about this. The good news
is that it's cleaned up and should be easier to maintain and to avoid
future modifications. The bad news is that this change itself will
break stuff, of course.
If you have any trouble building your Setup scripts, please let me
know. I really think that it was best to bite the bullet right now in
one big go instead of down the road with lots of little changes. I
have a lot more confidence in the hooks interface, and I don't
actually expect that it'll change as often.
I made the types more consistent, and made sure there are accessor
functions on each of the Flags types so that if the flags types change
in the future, it shouldn't break lots of code.
Another piece of good / bad news is that I decided not to get rid of
the pre & post hooks. They are nice for convenience and it wouldn't
be nearly so easy to write hooks without them.
That's bad because the interface to hooks is still pretty big, which
means that there's more likelihood that it'll change in the future.
Another weakness in the Hooks interface is that with command hooks
(like sDistHook) it's tempting to add parameters to them; basically
the stuff that we compute between the preSDist and sDist hook. I
removed such params and have their values computed elsewhere.
Cabal hackers, please avoid adding parameters to these command hooks
if at all possible in order to keep the interface steady. If you need
to compute a value to pass to these functions, compute it in the
function and / or make it available as a function that someone
crafting hooks can use as well, or consider whether it belongs in one
of the parameters already being passed to the hooks,
PackageDescription, LocalBuildInfo, UserHooks, Flags.
]
[make the order of params to cmd hooks consistent
[EMAIL PROTECTED]
[remove some flags from sdist, some cleanup
[EMAIL PROTECTED]
[clarifying and making flags types consistent
[EMAIL PROTECTED]
[changing tuple types to records w/ fields
[EMAIL PROTECTED]
[moving TODO stuff to wiki
[EMAIL PROTECTED]
[fix version number in fptools makefile to match .cabal file
[EMAIL PROTECTED]
[Add extraGHCiLibraries to the InstalledPackageInfo and extend the parser.
Duncan Coutts <[EMAIL PROTECTED]>**20060131163640]
[re-add the GNUmakefiles
Simon Marlow <[EMAIL PROTECTED]>*-20060123115236
These are now safe after we added "-f Makefile" to the make args when invoked
from the GHC build system. This repo should now be useable as the main
Cabal repo.
]
[re-add the GNUmakefiles
Simon Marlow <[EMAIL PROTECTED]>**20060123115236
These are now safe after we added "-f Makefile" to the make args when invoked
from the GHC build system. This repo should now be useable as the main
Cabal repo.
]
[TAG checkpoint
[EMAIL PROTECTED]
Patch bundle hash:
fb43e0281b694924e69c1cac3c9311aae1e67a9f
--- Begin Message ---
Hi,
I've been updating the various haskell ports in MacPorts and
have found a couple of problems with the latest Cabal (1.1.6,
as provided by ghc-6.6).
One is simply an infelicity that adds unnecessary work: why
does
./Setup register
fail with an error when used with an application that installs no
libraries? Could it simply return success and an informational
message like, "No library to install"? As it is, the user (or the
person
building the package) needs to know if a library is installed or
not. It's not a big deal in the case of packages which just provide
libraries, but it creates a difference in installation procedure for
packages that only provide applications and those that provide
applications along with libraries.
(For an application, the script version of registration, ./Setup
register --gen-script,
should just generate a stub that returns success, too.)
Having register simply return success for an application also makes the
library and application installation procedures identical.
From my experience in building packages, the more uniform the
installation procedure, the better.
The second problem I found is more serious. When installing a
library, in this case MissingH 0.16, I get the error:
ghc-pkg: /opt/local/lib/MissingH-0.16.0/ghc-6.6/include doesn't exist
or isn't a directory (use --force to override)
Error: Target com.apple.activate returned: shell command "/opt/local/
libexec/missingh/register.sh" returned error 1
Command output: Reading package info from stdin ... done.
ghc-pkg: /opt/local/lib/MissingH-0.16.0/ghc-6.6/include doesn't exist
or isn't a directory (use --force to override)
Warning: the following items did not execute (for missingh):
com.apple.activate
Error: Status 1 encountered during processing.
crossroads-able>
(the above is the output of the MacPorts portfile.)
The problem is that when the build is staged into a temporary
location so the files can be inventoried, an empty directory,
<prefix>/lib/MissingH-0.16.0/ghc-6.6/include is created. MacPorts
deletes this empty directory (along with a number of other unused
directories it creates in the staging process). The registration
process
requires the empty directory to be present and fails, as shown above,
if it is not.
The solution is simple: cabal can to drop a small file into any
directory it needs, say ".cabal-turd", preventing it from being deleted
(This is most easily done from the cabal side, rather than the packaging
system side, since the path has the haskell compiler and version
coded into it.)
I know that a case can be made for packaging systems preserving
all the directories created by a package, even empty ones. However,
Macports (formerly darwinports) and cabal played nicely in the past
and the 1.1.6 behavior breaks this.
Best Wishes,
Greg
_______________________________________________
Libraries mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/libraries
--- End Message ---
_______________________________________________
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
