cabal-scripts-0.1.1: cabal-scripts.cabal
Name: cabal-scripts
Version: 0.1.1
License: BSD3
License-file: LICENSE
Author: Henning Thielemann <darcs@henning-thielemann.de>
Maintainer: darcs@henning-thielemann.de
Category: Development
Build-type: Simple
Cabal-version: >=1.6
Synopsis: Shell scripts for support of Cabal maintenance
Description:
This is a collection of Bash shell scripts
for support of Cabal package development.
The scripts are installed in your @cabal/share@ directory,
thus you may extend your command search path accordingly.
.
If you are in the directory of @mypkg@
(the directory that contains @mypkg.cabal@),
then you may run scripts in the following way:
.
* @cabal-test dist/mypkg-0.1.tar.gz@:
Unpack the tarball in the @/tmp@ directory
and try to build it using Cabal.
This check helps to find missing files in the Cabal package description.
.
* @cabal-darcs-bump-version 0.2@:
Replaces the package and the repository version number
in your Cabal file by 0.2
and records an according Darcs patch.
.
* @cabal-darcs-upload 0.2@:
This command supports the following workflow:
Say, on Hackage there is version 0.0.1 of your package
and the cabal file in the darcs repository says @Version: 0.1@.
Now you decide to finish that version
and to work next on the version 0.2.
This is the time when you call @cabal-darcs-upload 0.2@.
The call runs @cabal-test@ and @cabal check@ before uploading.
Then it tags the repository with the current package version number.
Then it uploads the package to Hackage.
Finally it bumps the version of the package to @0.2@.
This workflow makes sure,
that you never have two different contents for the same version
in Hackage and in your darcs repository.
If you set the environment variable HACKAGEUSER,
then this will be automatically used for upload.
.
* @cabal-darcs-repository@:
Shows some lines of @Source-Repository@ fields,
that you may copy into @mypkg.cabal@.
We fetch the repository URL from Darcs files.
Unfortunately, as developer
you will certainly use a private read-write access
to your repository like @code.haskell.org:\/home\/user\/mypkg\/@,
whereas the Cabal field may contain a public read-only access,
such as @http:\/\/code.haskell.org\/~user\/mypkg\/@.
.
* @cabal-main-directory@
If started in a source sub-directory
then it prints the closest super-directory containing a cabal file.
This way a build script can automatically find the directory
where to run @cabal build@.
.
* @cabal-find-revdeps author package@:
Find all Cabal files of packages of a certain author
that import a certain package.
This is intended for updating a bunch of packages,
when a new version of a basic packages shall be supported.
In this use case, @author@ should be your name
and @package@ should be the basic package to adapt to.
Actually the script is very silly
and just scans for the author name and the package name
and does not check, where in the Cabal file they occur.
Thus be prepared for false positives search results.
The script also filters out package paths that contain underscores
in order to hide paths in @_darcs@ directories
and branched darcs repositories
that usually have names like @pkg_0@.
I advise to process the packages with
@
for pkg in \`cabal-find-revdeps author package\` ; do
(cd \`dirname $pkg\`; bash);
done
@.
This @for@ loop will take you successively into every package directory.
There you can perform some operations
and you can browse the shell history for the commands
you performed for the previous packages.
If you are finished with a package, then you just call @exit@,
and the @for@ loop automatically puts you in the next package directory.
See also package @cabal-sort@ that provides
the commands @cabal-sort@ and @ghc-pkg-dep@.
Data-Files:
cabal-test
cabal-find-revdeps
cabal-darcs-bump-version
cabal-darcs-repository
cabal-darcs-upload
Source-Repository this
Tag: 0.1.1
Type: darcs
Location: http://code.haskell.org/~thielema/cabal-scripts/
Source-Repository head
Type: darcs
Location: http://code.haskell.org/~thielema/cabal-scripts/
Library
Build-Depends: base>=1 && <10