On Thu, 24 Aug 2006, Isaac Jones wrote:
Isn't there a way for the haddock documents to be generated together
using certain haddock flags? Wouldn't it be nicer to just add this
feature to cabal somehow? Are there any existing proposals that solve
this question?
Somehow haddock can do this.
If a project consists of both a library and executables, the library
modules are re-compiled for each executable. (I use GHC.) That leads to
high space and time consumption. Is this a bug or a feature?
___
cabal-devel mailing list
On Mon, 4 Dec 2006, Simon Marlow wrote:
Henning Thielemann wrote:
If a project consists of both a library and executables, the library
modules are re-compiled for each executable. (I use GHC.) That leads to
high space and time consumption. Is this a bug or a feature?
A package that has
Since the .installed-pkg-config and .setup-config files depend on the
configure procedure and on the machine - shouldn't they be placed in
'dist', even more in a machine dependent sub-directory?
___
cabal-devel mailing list
cabal-devel@haskell.org
On Wed, 24 Oct 2007, Duncan Coutts wrote:
On Tue, 2007-10-23 at 22:21 +0200, Henning Thielemann wrote:
Does Cabal not support things like packages within a package simply
because Haskell libraries currently are not complex enough to require
such a feature, or is there a guiding design
On Wed, 24 Oct 2007, John D. Ramsdell wrote:
Henning Thielemann [EMAIL PROTECTED] writes:
It was requested several times but it seems not to be designed and
implemented so easily.
I bet it's easier than you think. You just have to dynamically
generate package configuration files, just
On Wed, 9 Jan 2008, Duncan Coutts wrote:
On Wed, 2008-01-09 at 10:27 +, Adrian Hey wrote:
Is this really the way tests are supposed to be included?
It doesn't seem workable to me. I wonder if it would be better to just
build the lib first (without tests) and then separately build
What about a Repository field which indicates where the (darcs) repository
of the project is located. Sometimes I abuse the Homepage field for this,
but I feel that's not the right way and sometimes there are both a
homepage and a repository located elsewhere.
On Wed, 20 Feb 2008, Lennart Kolmodin wrote:
Ross Paterson wrote:
On Wed, Feb 20, 2008 at 05:16:22PM +0100, Henning Thielemann wrote:
I have upgraded to Cabal 1.2 while still using GHC-6.4.1. In the Haskore
project there is the module NewResolutions.lhs which let GHC run into
extensive
I like to use Haddock markup like bird track () and enumerations (*) in
the Description field of a package. However I can't get it working, the
mentioned markup is simply ignored. The content of the description field
must be indented, is it unindented before passing to Haddock?
Consider
http://code.haskell.org/mohws/mohws.cabal
When I include Paths_mohws as Other-Modules, 'cabal haddock' aborts with:
thiel...@euler:~/programming/haskell/mohws cabal haddock
Preprocessing library mohws-0.2.0.1...
Preprocessing executables for mohws-0.2.0.1...
Running Haddock for
What do I have to do to get my patches to Cabal accepted?
'http://hackage.haskell.org/trac/hackage/attachment/ticket/602/jhc.darcs'
-- Forwarded message --
Date: Mon, 02 Nov 2009 23:59:11 -
From: Hackage t...@galois.com
Reply-To: cabal-devel@haskell.org
Cc:
On Tue, 1 Jun 2010, Erik Hesselink wrote:
On Tue, Jun 1, 2010 at 11:30 AM, Henning Thielemann
As far as I understand the problem is only a problem with an older
version of Cabal and cabal-install. Is there a reason why you can't
update your Cabal to a current version? I still do not feel
I am lost. Cabal-install says 'there is no available version of parsec that
satisfies ==3.1.1', but ghc-pkg says I have this parsec version installed.
mypkg$ cabal install --constraint=parsec==3.1.1
Resolving dependencies...
cabal: There is no available version of parsec that satisfies
Currently I am trying to convert the test suite in utility-ht to Cabal's
new Testing feature. The documentation in
http://www.haskell.org/ghc/docs/7.0.2/html/libraries/Cabal-1.10.1.0/Distribution-TestSuite.html
mentions the packages cabal-test-hunit, cabal-test-quickcheck1, and
On Sun, 13 Mar 2011, Thomas Tuegel wrote:
The hope is that once the library interface is finished, the
QuickCheck author(s) would choose to support it directly. Then, you
wouldn't need cabal-test-quickcheck{1,2} and you could write test
suites that work with either version.
I would also
On Thu, 22 Nov 2012, Simon Peyton-Jones wrote:
The solution is obvious: we should make it possible to instally
yesod-platform-2.7 twice,
once version depending on data-default-0.4
once version depending on data-default-0.5.
Does ghc-pkg allow to have two different versions of
On Thu, 22 Nov 2012, Brandon Allbery wrote:
I am wondering if we're trying to solve the problem in the wrong way.
The core of the problem is that various things get baked into libraries
in the name of optimization, such that a given binary library has
dependencies on precise versions of
On Sun, 17 Mar 2013, Ian Lynagh wrote:
I think it would be feasible to stop GHC itself from using the human
readable format. The only place I can think of it being used is in the
package database, but we could use either Read/Show for that, or just
exclusively use the binary format.
I
On Sun, 17 Mar 2013, Ian Lynagh wrote:
On Sun, Mar 17, 2013 at 09:04:58PM +0100, Henning Thielemann wrote:
On Sun, 17 Mar 2013, Ian Lynagh wrote:
I think it would be feasible to stop GHC itself from using the human
readable format. The only place I can think of it being used
On Wed, 4 Sep 2013, Johan Tibell wrote:
* GHCi support. It's now much easier to use ghci when developing your
packages, especially if those packages require preprocessors (e.g.
hsc2hs).
That's a great feature! How can I configure Cabal to start ghci with
certain options? I like to enable
I am trying to compile cabal-install-1.18.0.2 on GHC-6.12.1. It aborts
with:
...
[12 of 73] Compiling Distribution.Client.Compat.Semaphore (
Distribution/Client/Compat/Semaphore.hs,
dist/build/cabal/cabal-tmp/Distribution/Client/Compat/Semaphore.o )
On Mon, 28 Oct 2013, Johan Tibell wrote:
This is my fault. I don't know if it's worth another Cabal release to
fix it though. 6.12 is more than 3 years old now.
I have three (remote) machines where I could compile and run my stuff, all
of them have GHC-6.12.1 (Ubuntu 10.04 LTS). If mask_
Following Mikhail Glushenkov's advice I have prepared a separate tool
that checks PVP compliance of imports as proposed in:
https://github.com/haskell/cabal/issues/1703
There remain some problems:
* How can I exclude automatically generated modules like Path_*.hs from
the check?
* How can
Am 28.02.2014 22:06, schrieb Roman Cheplyaka:
* Johan Tibell johan.tib...@gmail.com [2014-02-28 21:23:23+0100]
* How can I access modules that are preprocessed? HSC processed modules
are stored in dist/build, but CPP processed modules are not stored anywhere.
Perhaps because GHC applies CPP
Am 28.02.2014 22:31, schrieb Roman Cheplyaka:
* Henning Thielemann lemm...@henning-thielemann.de [2014-02-28 22:21:39+0100]
[1]: http://hackage.haskell.org/package/hse-cpp
It would still be nicer to have a solution that also works with HSC,
CHS and maybe others. I have also not checked LHS so
Am 28.02.2014 23:00, schrieb Roman Cheplyaka:
* Henning Thielemann lemm...@henning-thielemann.de [2014-02-28 22:48:59+0100]
Nice! Is there a recommended way to transfer CPP options from the
Cabal file to the CpphsOptions record?
Yes, haskell-packages[2] lets you easily create a cabal
Am 01.03.2014 16:57, schrieb Henning Thielemann:
Treating check-pvp as compiler driven by Cabal sounds reasonable, since
this would do all the preprocessing stuff and would also work on
tarballs etc. However the haskell-name framework seems to expect a
binary executable as compiler. According
Am 01.03.2014 22:11, schrieb Roman Cheplyaka:
* Henning Thielemann lemm...@henning-thielemann.de [2014-03-01 16:57:56+0100]
My problem is: The checker needs to read the package description in
order to classify the dependency ranges. The compiler has no access
to the package description
Am 01.03.2014 22:11, schrieb Roman Cheplyaka:
Good point. I've added 'customMain' to git repo. Let me know if it works
for you.
I can't find Distribution.HaskellSuite.Compiler.customMain. :-(
I pulled from master of git://github.com/haskell-suite/haskell-packages.git
Am 01.03.2014 22:29, schrieb Roman Cheplyaka:
* Henning Thielemann lemm...@henning-thielemann.de [2014-03-01 19:02:35+0100]
I got some problems. Using NamesDB as in hs-gen-iface works, but I
guess, I do not need NamesDB and thus haskell-names.
Certainly not.
Perhaps the compiler abstraction
Am 01.03.2014 23:37, schrieb Roman Cheplyaka:
* Henning Thielemann lemm...@henning-thielemann.de [2014-03-01 22:31:56+0100]
Am 01.03.2014 22:11, schrieb Roman Cheplyaka:
Good point. I've added 'customMain' to git repo. Let me know if it works
for you.
I can't find
Am 01.03.2014 23:48, schrieb Henning Thielemann:
[6 of 8] Compiling Distribution.HaskellSuite.Compiler (
src/Distribution/HaskellSuite/Compiler.hs,
dist/build/Distribution/HaskellSuite/Compiler.o )
src/Distribution/HaskellSuite/Compiler.hs:21:5:
Not in scope: `customMain'
I guess
In a project I have currently some program text embedded as String in the
source code. I like to move that to an extra file, such that I can test
the program without running the Haskell code and such that non-Haskell
programmers can adapt the text. However, I hesitate to use the Data-Files
On Fri, 3 Mar 2017, Edward Z. Yang wrote:
One of the tracking bugs we have for this issue:
https://github.com/haskell/cabal/issues/4120
Note that the data file directory can be overridden
with environment variables, that might be good enough to
work around.
It would be really nice if inplace
35 matches
Mail list logo
