Here's a status update.
## Faster builds
We've made good progress on making things faster. In particular, we've
implemented:
* Re-linking avoidance (https://github.com/haskell/cabal/pull/1537). This
is really useful if you have e.g. many test suites and only one needs to be
rebuilt due to some
On Sat, Sep 7, 2013 at 1:29 PM, Herbert Valerio Riedel wrote:
sounds like https://github.com/haskell/cabal/pull/1455
>
That‘s great if they’re adding a warning for modules, but it'd be even
better if it would warn about any missing files not just modules. For
example, extra-source-files that are
On 2013-09-07 at 09:00:47 +0200, Sergei Trofimovich wrote:
[...]
> 2. Would be nice for cabal build somehow check that 'ghc --make'
> can't access files not present in .cabal file.
>
> That way amount of packages with missing uploaded tests
> could be shunken down.
>
> Otherwise w
On Wed, 4 Sep 2013 21:14:03 -0700
Johan Tibell wrote:
> Hi all,
>
> With 1.18 out the door it's time to look towards the future. Here are
> the major themes I'd like to see us work on next:
While those are grand and nice goals I'd like to see some progress
in tiny bits - just verifying some bas
we just do it? Isn't it more important, for our
| users, than the other things Johan lists below?
| >
| > Simon
| >
| >
| >
| > | -Original Message-
| > | From: cabal-devel [mailto:cabal-devel-boun...@haskell.org] On Behalf
| Of
| > | Johan Tibell
| > | Sent: 05 Septemb
On 2013-09-06 01:04, Johan Tibell wrote:
> You raise a good point that sandboxing only addresses the issue of
> conflicts between two projects (that want to use different
> dependencies), but not the issue of actually using two different
> versions of a package (at different versions) in a single p
fyi, below you can find an expanded list of related links.
I do appreciate the new sandboxing feature in 1.18 and I think it is a
great feature, but it is not addressing the core issue here: adding support
for multiple instances of the same version. It also seems to me that
supporting this would b
You raise a good point that sandboxing only addresses the issue of
conflicts between two projects (that want to use different
dependencies), but not the issue of actually using two different
versions of a package (at different versions) in a single project*.
The latter is valuable but also a bit tr
users, than the other things
> Johan lists below?
>
> Simon
>
>
>
> | -Original Message-
> | From: cabal-devel [mailto:cabal-devel-boun...@haskell.org] On Behalf Of
> | Johan Tibell
> | Sent: 05 September 2013 05:14
> | To: cabal-devel@haskell.org
> | Subject: What&
On Thu, Sep 05, 2013 at 12:18:15PM -0700, Johan Tibell wrote:
> On Thu, Sep 5, 2013 at 12:06 PM, Iustin Pop wrote:
> > On Wed, Sep 04, 2013 at 09:14:03PM -0700, Johan Tibell wrote:
> >> ## Do the right thing automatically
> >>
> >> The focus here should be on avoiding manual steps the cabal could
On Wed, Sep 04, 2013 at 09:14:03PM -0700, Johan Tibell wrote:
> Hi all,
>
> With 1.18 out the door it's time to look towards the future. Here are
> the major themes I'd like to see us work on next:
[…]
> ## Do the right thing automatically
>
> The focus here should be on avoiding manual steps t
On Thu, Sep 5, 2013 at 12:06 PM, Iustin Pop wrote:
> On Wed, Sep 04, 2013 at 09:14:03PM -0700, Johan Tibell wrote:
>> ## Do the right thing automatically
>>
>> The focus here should be on avoiding manual steps the cabal could do
>> for the user.
>>
>> * Automatically install dependencies when nee
| > Can I ask what the Cabal team's position is with respect to the
| question of allowing the same package to be installed several times,
| each compiled against a different collection of dependencies?
|
| I think that we all agree that in the long term a Nix-like package
| database is the ideal
Hi Simon,
On Thu, Sep 5, 2013 at 9:15 AM, Simon Peyton-Jones
wrote:
> Can I ask what the Cabal team's position is with respect to the question of
> allowing the same package to be installed several times, each compiled
> against a different collection of dependencies?
I think that we all agree
Original Message-
| From: cabal-devel [mailto:cabal-devel-boun...@haskell.org] On Behalf Of
| Johan Tibell
| Sent: 05 September 2013 05:14
| To: cabal-devel@haskell.org
| Subject: What's next?
|
| Hi all,
|
| With 1.18 out the door it's time to look towards the future. Here
Hi Johan,
On Thu, Sep 5, 2013 at 6:14 AM, Johan Tibell wrote:
>
> * Build modules in parallel. This fine granularity would let us
> making building a single package faster, which is the most common case
> after all. There has been some GSoC work here e.g.
> http://hackage.haskell.org/trac/ghc/ti
Hi all,
With 1.18 out the door it's time to look towards the future. Here are
the major themes I'd like to see us work on next:
## Faster builds
There are several interesting things we could do and are doing here.
* Avoid relinking if possible. This reduces incremental build times
(i.e. when y
17 matches
Mail list logo
