ion/Server/Features/Tags.hs +2
Sat Jul 23 01:16:14 BST 2011 David Lazar
* Improve deprecation form.
Ignore-this: ebcd1fff01fecf29366108f024f959c3
M ./Distribution/Server/Features/Html.hs -3 +3
Sat Jul 23 01:16:35 BST 2011 Duncan Coutts
* Change how we handle exceptions that resul
Sun Aug 7 21:33:37 BST 2011 Duncan Coutts
* Rename the server Config to ServerEnv to reduce confusion
Ignore-this: 177124869e8dcb6368eedd4c3602c76d
M ./Distribution/Server.hs -10 +11
M ./Distribution/Server/Features.hs -21 +20
M ./Distribution/Server/Features/BuildReports.hs -3
Fri Aug 12 15:07:17 BST 2011 Duncan Coutts
* Fix <> on init
Ignore-this: 174499c5ba3ba65d5cec609d29cf85a4
M ./Distribution/Server/Features/Users.hs -2 +2
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/m
Sun Aug 7 23:27:09 BST 2011 Duncan Coutts
* Rename the HackageModule/Feature type and some members
Ignore-this: 12950620308852e004706f06099e5165
M ./Distribution/Server.hs -3 +3
M ./Distribution/Server/Features.hs -6 +6
M ./Distribution/Server/Features/BuildReports.hs -4 +3
Sat Aug 13 16:18:39 BST 2011 Duncan Coutts
* Don't need ExistentialQuantification in Distribution.Server.Features anymore
Ignore-this: b19b78e679a00bf1746b9461788e2691
M ./Distribution/Server/Features.hs -2 +1
Sat Aug 13 16:19:13 BST 2011 Duncan Coutts
* Rena
Wed Oct 5 12:56:03 BST 2011 Duncan Coutts
* Use version in hackage-mirror user agent string
Ignore-this: c1d9136810b593bf84503f436d3bab8
M ./MirrorClient.hs -1 +3
Wed Oct 5 12:56:35 BST 2011 Duncan Coutts
* Keep mirror client files in per-server dirs
Ignore-this
Thu Oct 6 11:29:45 BST 2011 Duncan Coutts
* First go at adding continuous/live mirroring
Ignore-this: 69423437dcf02091da86ae3480bc128d
M ./MirrorClient.hs -32 +105
M ./hackage-server.cabal -1 +1
Thu Oct 6 12:09:20 BST 2011 Duncan Coutts
* Improve the mirror client help
Tue Sep 27 09:59:51 BST 2011 Max Bolingbroke
* Have the MirrorClient use the system proxy
Ignore-this: c2f1dc9d7ae36a9acc200a4f527f432
M ./MirrorClient.hs +1
Tue Sep 27 10:35:04 BST 2011 Max Bolingbroke
* Split out client functionality unrelated to mirroring from MirrorClient
Ignor
Sun Oct 9 17:29:55 BST 2011 Duncan Coutts
* Rework the async var to batch updates and amortise the work
Ignore-this: 7541312d71e65f8effa0c4ba33d0b480
Previously, every single write to the var was laboriously evaluated
and since jobs keep comming in faster than they can be evaluated
Sun Oct 9 21:30:32 BST 2011 Duncan Coutts
* Implement robust continuous/live mirroring
Ignore-this: f8efccf223a32f39a7d7fc1cfa599413
The HTTP error handling infrastructure is substantially changed.
Unfortunately this means it's not shared with the build bot client
anymore. That c
Mon Oct 10 09:17:13 BST 2011 Duncan Coutts
* Remove most of the package checks for the mirroring case
Ignore-this: 6d2f4928f44edccad3cd34cc7898de93
For mirroring, we have to be able to upload packages
that would fail the current QA checks.
M ./Distribution/Server/Features/Mirror.hs
Thu Oct 20 21:19:24 BST 2011 Duncan Coutts
* Link with the crypt lib
Ignore-this: d20e90b6668040dcfebc462933dff14d
Except on OSX where it's in libc.
M ./hackage-server.cabal +3
___
cabal-devel mailing list
cabal-devel@haskell.org
Sat Oct 22 14:36:25 BST 2011 Bas van Dijk
* crypt is not thread-safe so synchronize acces to it using a lock (MVar ()).
Ignore-this: f322b7b456cd0db8d146397252a8e979
M ./Distribution/Server/Framework/AuthCrypt.hs -1 +7
___
cabal-devel mailing
Oct 23 14:03:57 BST 2011 Duncan Coutts
* Drop dependency on old-time
Ignore-this: 5f59217f285c83117fa3f6d3e11bdd46
M ./Distribution/Server/Pages/Recent.hs -2 +1
M ./hackage-server.cabal -3
Sun Oct 23 14:05:04 BST 2011 Duncan Coutts
* Allow building with older containers and
Wed Oct 12 18:24:51 BST 2011 Duncan Coutts
* Remove the JSON feature
Ignore-this: 8e1577b487e73d2738409e4f95798ff0
We're going to factor it differently. Each feature can provide its
resources in multiple formats: native, json, xml. This is a more
modular way of partitioning t
Tue Feb 14 03:24:29 GMT 2012 Duncan Coutts
* Add a --keep-going flag to the mirror client
Ignore-this: 5983c99a11c72151851a1a140e87fd3a
It already does this for --continuous, this lets us do it in the
one-shot mode too.
M ./MirrorClient.hs -8 +15
Tue Feb 14 16:49:11 GMT 2012 Duncan Coutts
* Use line buffering for mirror client
Ignore-this: f63019a6c722a2bd6751ef86a3e84ea2
Handy when monitoring log files to get more incremental output.
M ./MirrorClient.hs +2
___
cabal-devel mailing
Thu Feb 23 14:19:17 GMT 2012 Duncan Coutts
* Add package tarball redirects for current cabal-install versions
Ignore-this: 16df6b5c8b71e964a4177ed575b06984
They expect /package/foo-1.0.tar.gz
rather than /package/foo-1.0/foo-1.0.tar.gz
M ./Distribution/Server/Features
Tue May 2 18:46:30 BST 2006 Duncan Coutts <[EMAIL PROTECTED]>
* Change calls to 'make' into '$(MAKE)'
This is the portable thing to do and fixes things on FreeBSD where make/=gmake
New patches:
[Change calls to 'make' into '$(MAKE)'
Duncan Co
uld we want to make it
harder to use by insisting that pkg-config features are accessed via
Setup.lhs rather than a simple one line in the .cabal file.
I don't know which is the best way. It comes back to the dilemma over
how much goes into the declarative .cabal file and how much goes into
opaq
On Wed, 2006-05-24 at 11:28 +0100, Simon Marlow wrote:
> Duncan Coutts wrote:
>
> > It'd be very convenient to be able to just say:
> >
> > pkg-config-depends: dbus-1 >= 0.60
>
> The idea seems reasonable to me... just one question: what happens on
&
--lflag=-l).
Tue Jul 4 01:19:26 BST 2006 Duncan Coutts <[EMAIL PROTECTED]>
* Change flags passed to hsc2hs
The extra-libraries must be passed as -L-l${lib} or linking the C prog
that hsc2hs generates may fail if any symbols are referenced.
Also can't use cppOptions function
ng easier? Where did we
get with that?
Duncan
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org//mailman/listinfo/cabal-devel
On Thu, 2006-07-06 at 10:43 +0100, Duncan Coutts wrote:
> Hi Cabal hackers,
>
> For c2hs we've run into a problem. See the thread about c2hs on window
> over on the haskell list.
>
> c2hs wants to install a data file (actually a .hs source file) and wants
> to know wh
On Thu, 2006-07-06 at 12:12 +0100, Duncan Coutts wrote:
> On Thu, 2006-07-06 at 10:43 +0100, Duncan Coutts wrote:
> > Hi Cabal hackers,
> >
> > For c2hs we've run into a problem. See the thread about c2hs on window
> > over on the haskell list.
> >
> >
On Thu, 2006-07-06 at 15:59 +0100, Duncan Coutts wrote:
> Ok, along a similar theme...
>
> We provide the Paths_${projname}.hs module, as a little extra there it
> provides the current version number. Perhaps we could generalise that
> and provide the whole cabal file (using t
Oops, I accidentally discarded this email in some overzealous
moderating.
Forwarded Message
> From: Henning Thielemann <[EMAIL PROTECTED]>
> To: Bulat Ziganshin <[EMAIL PROTECTED]>
> Cc: cabal-devel@haskell.org
> Subject: Cabal and dependencies (Moved from Haskell-Cafe: Haskore
>
On Thu, 2006-07-20 at 11:49 -0700, Isaac Jones wrote:
> Patches from Jeremy Shaw. Duncan, can you look at these and apply?
>
I'll try and test it tomorrow.
Duncan
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.o
On Thu, 2006-07-20 at 11:49 -0700, Isaac Jones wrote:
> Patches from Jeremy Shaw. Duncan, can you look at these and apply?
The patch looks mostly ok to me. So it just turns on or off the building
of normal libs.
The TH thing - can we check that this is really the right thing to do?
So the c
On Wed, 2006-07-26 at 12:45 -0700, Isaac Jones wrote:
> Does anyone have objections to this?
Nope, looks fine to me.
The patch doesn't actually apply cleanly but I see what it's doing and
agree with the change.
Duncan
___
cabal-devel
On Fri, 2006-07-21 at 16:00 +0100, Duncan Coutts wrote:
> On Thu, 2006-07-20 at 11:49 -0700, Isaac Jones wrote:
> > Patches from Jeremy Shaw. Duncan, can you look at these and apply?
>
> The patch looks mostly ok to me. So it just turns on or off the building
> of normal libs.
On Fri, 2006-07-28 at 04:56 +0200, Bertram Felgenhauer wrote:
> Hi,
>
> I've discussed the patch with Duncan Coutts. The result is the attached
> revised patch. Changes:
>
> - fix the handling of 'x-' fields - with the previous patch cabal would
> com
a program rather than a lib? Should
we vanilla-compile all the modules but not link then into a binary and
then compile again with profiling and then link those into a binary?
And presumably we would only expect this to work with GHC 6.6.
Duncan
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org//mailman/listinfo/cabal-devel
Thanks Bertram.
Simon: is this definitely what we will need for GHC 6.6?
If so we can make Cabal pass it depending on the GHC version.
Duncan
On Sun, 2006-07-30 at 07:20 +0200, Bertram Felgenhauer wrote:
> Simon's recent changes to the package system have the effect that
>
On Tue, 2006-08-01 at 12:12 +0100, Simon Marlow wrote:
> Duncan Coutts wrote:
> > Specifically: if the user asks for profiling but not vanilla versions of
> > libs and they're using TH then we should build vanilla libs first and
> > then profiling libs. However at install
On Tue, 2006-08-01 at 12:23 +0100, Simon Marlow wrote:
> Duncan Coutts wrote:
> > Isaac: I'm happy with both of these patchs if you are.
> >
> > I've also got a slight improvement on the docs for liftField which I'll
> > add if these go in.
>
>
On Tue, 2006-08-01 at 11:26 -0700, Isaac Jones wrote:
> Duncan Coutts <[EMAIL PROTECTED]> writes:
> >> - fix the handling of 'x-' fields - with the previous patch cabal would
> >> complain about these as unknown in most contexts
>
> Right, it sh
l
Our main bottleneck on Cabal development is not the lack of people
pointing out shortcomings but the number of people sending patches.
Send more patches, the last ones tasted great!
Duncan
(wearing his Cabal patch reviewer hat)
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
Another reason is that we do not have any standard way of
detecting cabal-installed programs like we do with libs so detecting
tools is more ad-hoc than libs.
There is a slight danger here of duplicating too much on the job of a
distro package manager.
Duncan
___
s what
it means then it should be an error condition with a helpful message to
use "build-depends: foo > 1 && < 3" instead.
Similarly if we go with "packages(foo >1 && < 3)" meaning something
different from "packages(foo > 1) && packages(foo < 3)" then is the
latter not simply an error?
Duncan
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
tion: package(base < 1.1)
hs-src-dirs: compat
So I guess the suggestion is that all deps are given up front and
resolved. Then depending on what deps were chosen we can have other
effects on the build like specifying extra src dirs or flags or
whatever, but not specifying any more build-depends. S
ose to our current configurations proposals but is not evil?
Duncan
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
On Thu, 2006-08-10 at 22:13 +0100, Duncan Coutts wrote:
> So, with this in mind, can we come up with a syntax & semantics that is
> close to our current configurations proposals but is not evil?
One thing that might help is if we split the 'package' condional test
into two
clear
what can be overridden.
> I'm back to the two-argument package() conditional, because it's actually
> useful. package(Hunit>=1, 1.1) is not the same as package(HUnit-1.1) or even
> package(HUnit>=1 && 1.1). It says "the dependency HUnit>=1 resolves
& semantics must be such that all decisions based on what's in
the environment be overridable.
Interestingly for the fps/base case we do not need a user flag, it
really is an automatic decision. Once we've fixed the version of base
we're using then there is no choice about whethe
On Fri, 2006-08-11 at 15:08 +0100, Duncan Coutts wrote:
> On Fri, 2006-08-11 at 12:15 +0100, Simon Marlow wrote:
>
> > The whole thing is easier to understand IMO, and it's simple to implement
> > too:
> > no ordering, conditionals can be evalutated independently.
On Fri, 2006-08-11 at 15:40 +0100, Simon Marlow wrote:
> Duncan Coutts wrote:
> > On Fri, 2006-08-11 at 12:15 +0100, Simon Marlow wrote:
>
> >>One goal (that I keep having to remind myself of) is that a .cabal file
> >>should
> >>be modifyable by an I
l
implementation, eg ghc-x.y, hugs-x.y etc not to versions of libraries.
Yes, I think it's a quite reasonable argument to extend this to include
exact versions of libraries that it has been tested with.
What do others think?
Duncan
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
you to
> go get happy?
Yes please. Send patches! :-)
> PS. I'm really liking this Cabal thing, its a very nice concept.
Glad you've come round to the idea. :-) It really isn't an anti-windows
conspiracy ;-)
Duncan
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
Wed Aug 2 18:59:22 BST 2006 Duncan Coutts <[EMAIL PROTECTED]>
* Try to support TH with profiling. See ticket #91.
This needs testing.
Fri Aug 18 02:04:49 BST 2006 Duncan Coutts <[EMAIL PROTECTED]>
* Add xargs function and use it when linking.
When using GHC's --spl
n some cases for Windows [2], but upon
> talking about it with Duncan, in irc, there's few exta points:
> * Some unixy shells apparently have restrictions as well, so this
>shouldn't be just Windows.
> * On my old implementation, I just split the commandlines by filecoun
On Fri, 2006-08-18 at 12:20 +1000, Conrad Parker wrote:
> On Thu, Aug 17, 2006 at 03:29:00PM +0100, Duncan Coutts wrote:
> > On Thu, 2006-08-17 at 14:50 +0100, Neil Mitchell wrote:
> > > Hi,
> > >
> > > First off, being a windows user, having a configure/build
.
Did you really need Cabal's FilePath? How about using Neils new improved
stand alone version.
Isaac: what do you think?
Duncan
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
in relative to the current darcs
version of Cabal?
Cheers.
Duncan
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
On Mon, 2006-08-21 at 15:31 +0100, Neil Mitchell wrote:
> Hi
>
> > The change itself looks fine. It didn't apply cleanly however, it gave
> > conflicts. Would you mind sending it again relative to the current darcs
> > version of Cabal?
>
>
hat
> module is there so that cabal can use it internally. If everyone
> starts to use it, then we start to get spurious dependencies on cabal;
> once we remove that module, other people's code will break for no good
> reason. Best to jus
bit
should probably use pipes rather than outputting to a file
and then reading the file.
I didn't want to just push these changes, so can someone else
give them a quick look over and commit. Cheers.
Duncan
Wed Aug 23 11:54:12 BST 2006 Duncan Coutts <[EMAIL PROTECTED]>
* Be cle
emain public in this release and seek a
better solution for the next release.
BTW, you can see the complete set of Gentoo's Haskell packages here:
http://www.haskell.org/~gentoo/gentoo-haskell/
(mostly under dev-haskell/)
Gentoo users & developers can use this package collection as a port
l.org
We're particularly interested of course in anything that worked before
and is now broken.
Duncan
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
Thanks for the report! I think that this has already been fixed with
> the new cabal release. Is that so, Duncan?
>
> We had thought to hide FilePath, but it's apparently too popular to
> keep from the people.
That's correct. It's exposed in the latest release candidate
e ability to specify
arbitrary package databases? What is the use case?
(BTW, I'm not saying we don't need it, I'm just wondering what people
want it for)
Duncan
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
On Sat, 2006-09-16 at 08:54 +0200, Duncan Coutts wrote:
> Note that there is already a register --inplace flag to register a
> package in the build tree. To allow multiple packages to be built
> against each other inplace we'd also need some flag for configure.
>
> Would t
there.
Yes, Lennart Kolmodin was just investigating this problem for Gentoo and
came to a similar conclusion.
We can't pass all the cc-options to hsc2hs or cpphs, we'd have to filter
them which seems a bit ugly. The other ugly option is to add thes
On Tue, 2006-10-03 at 00:26 +0100, Duncan Coutts wrote:
> On Tue, 2006-10-03 at 00:07 +0100, Ross Paterson wrote:
> > To elaborate, when cpphs is called from the haddock phase, it's not
> > passed the cpp arguments that are used by build. I think Cabal needs
> > a
ally the last part of that file.
I think this needs fixing asap since the cpphs code path gets used in
preference to the ghc -E path if cpphs is installed. In this example the
symptoms are not too bad as it seems only to be affecting haddock, but I
fear it may break
On Mon, 2006-10-09 at 12:33 +0100, Malcolm Wallace wrote:
> Duncan Coutts <[EMAIL PROTECTED]> wrote:
>
> > building the haddock docs for HUnit when cpphs is
> > installed fails. This is because the
> > Distribution.PreProcess.Unlit.unlit code produces incorrect outp
The Haskell Cabal
The Common Architecture for Building Applications and Libraries.
http://haskell.org/cabal/
Cabal version 1.1.6 is now available.
It is included in GHC version 6.6. For other Haskell implementations or
older versions of GHC you can install it separately:
next release, and I'll make sure this
> problem
> doesn't crop up with the Happy & Alex releases.
And if anyone wants to make cabal's sdist include pre-built .hs versions
of happy/alex .y/.x files then that'd be great. Currently that's a
manual step.
Duncan
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
> echo 'name: OpenGL
> [...]
> OpenGL is the industry's most widely used and supported 2D and 3D
> [ ^^^ ]
> [...]
> haddock-html: /usr/share/OpenGL-2.1/doc/html' | /usr/bin/ghc-pkg update -
Fixed. Thanks.
Duncan
__
On Tue, 2006-10-17 at 16:40 +0100, Ian Lynagh wrote:
> Hi all,
>
> I think Duncan has already said that we need a way to have .x and .y
> files included in sdists, but we also need a clean variant or flag that
> doesn't clean them. Apologies if this has also already been
igure out
how to use isolated .dlls and manifests and all that).
So perhaps including a recent tar prog (that understands -z) would be
the way forward. We'd need this for cabal-install in future, it's not
just sdist.
Duncan
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
extra build-deps introduced by some configuration stanza.
How about we start with True as the
Can anyone see if it's possible to find out a priori if there is a set
of packages that can satisfy the conditional constraints. Is this a
standard constraint solving problem? Does it have a solution?
Here's a nasty example:
configuration: using(P = 1.1)
build-depends: P = 1.0
configuration: using(P = 1.0)
build-depends: P = 1.1
Duncan
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
On Wed, 2006-10-25 at 01:36 +0100, Duncan Coutts wrote:
> I would like to re-propose the last scheme that I cam up with. I'll try
> to make it a concrete proposal as well as giving some motivating
> examples to give the intuition of the meaning.
As a quick addendum, some comment
On Tue, 2006-10-24 at 21:45 -0500, Brian Smith wrote:
> (sorry, I responded to the wrong list)
>
> On 10/24/06, Duncan Coutts
> <[EMAIL PROTECTED]> wrote:
> On the other hand, in Gtk2Hs I know one case where we do this.
> We have a
> Graphics.U
On Wed, 2006-10-25 at 12:32 +0300, Einar Karttunen wrote:
> On 25.10 01:36, Duncan Coutts wrote:
> > I would like to re-propose the last scheme that I cam up with. I'll try
> > to make it a concrete proposal as well as giving some motivating
> > examples to give th
on of a
> given library installed at the same time?
You can't. No current Haskell implementation supports this (without
doing things manually like using separate package databases / search
paths).
What you want is what the ghc build system refers to as a 'way'. It's a
whole other discussion I think.
Duncan
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
guess, if it's pretty common to
> have this older version of tar.
As Neil said, Windows users don't have tar/gzip at all.
Duncan
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
ely and not allow some fields to be used in configuration
stanzas. If a real need arises we can review.
Duncan
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
On Wed, 2006-10-25 at 22:19 -0500, Brian Smith wrote:
> On 10/24/06, Duncan Coutts <[EMAIL PROTECTED]> wrote:
> Hi All,
>
> Before the 6.6 release we had a longish discussion on how to
> do
> configurations and their sema
make wierdy packages, you also
have to go to greater lengths technically. :-)
Duncan
On Thu, 2006-10-26 at 03:06 +0300, Einar Karttunen wrote:
> On 25.10 19:08, Duncan Coutts wrote:
> > We are introducing a big new feature here, we can start out
> > conservatively and not allow
r than returning the day of the
> week plus the birthday of your best friend (which makes similar sense
> to returning the installation status of an non-os component!).
I agree.
I think they should be using some other method to find cygwin
components. Eg they can check if the posix package is ava
On Sun, 2006-10-29 at 10:55 +0200, Einar Karttunen wrote:
> On 26.10 15:49, Duncan Coutts wrote:
> > Yes, if we were to not allow changing the exposed modules then people
> > could achieve the same effect using CPP.
>
> Can we agree at least on a subset of the functionality
On Sun, 2006-10-29 at 18:26 +0200, Einar Karttunen wrote:
> On 29.10 14:56, Duncan Coutts wrote:
> > We do have to bear in mind how hard it'll be for cabal-get to be able to
> > do dependency analysis. The decisions we make about optional
> > configurations has a big imp
clear how we should make it work with configurations
where we need to be able to add additional constraints on a package
version:
build-depends: foo
configuration: os(windows)
build-depends: foo >= 2.0
So should this mean that we get two versions of package foo? We need to
be able to both in fact
he major
> outstanding issues, but let me know if I missed one.
Ta! :-)
> - Varying exposed modules
>
> First, as Duncan said, I don't think the exposed modules should be able
> to vary as then (as Brian Smith said) dependencies just don't make
> sense. Yes, base is
der that a distro package manager will pick.
This isn't that bad but it's not exactly nice or intuitive.
Duncan
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
u investigate what external functions we need exactly and if
they're exported from System.Win32.
I'll gladly accept a patch to do this.
Duncan
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
e to have to say:
executable: foo.exe
since then it's not portable to non-windows. So how can we infer that no
extra .exe extension is required? Is it reasonable to guess that if it
already has one '.' in the name that we shouldn't add a .exe extension?
Duncan
; program depend on
Cabal. Perhaps it's just as bad to make it depend on Win32, but I think
it's probably less bad. Or it could go in base or we could leave it as
is as an FFI import.
Duncan
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
n32 package or any non-base package.
It's not something that people would really like to put into base
because it's not portable. There really is no equivalent to
GetModuleFileName in Unix (indeed deliberately so because you can delete
the binary while the program is still running).
I
version of it for Haskell implementations that lack
it however the current #ifdefs mean that for hugs we don't use the
bundled version but just import the standard version that hugs comes
with.
So the obvious solution is that we should change the #ifdefs
I agree completely. I'd be happy to accept patches along these
lines. :-)
Duncan
On Tue, 2006-11-21 at 18:47 +, Ian Lynagh wrote:
> [forwarding this manually as the BTS doesn't send to a mailing list;
> the bug is at http://hackage.haskell.org/trac/hackage/ticket/101 ]
>
t least!) to tell make "setup depends on whichever of Setup.hs and
> Setup.lhs exists".
Note that in future we intend to allow there being no Setup.(l)hs at all
when using cabal-setup. No Setup.(l)hs file would be equivalent to the
basic one that uses defaultMain.
So how would that
t actually
> create the directory?
I think we shouldn't be making package files that make ghc look for
include dirs if there are actually no headers needed. So there should be
no problem later with deleting empty dirs. We should not make and use
dirs in the first pl
ction be
simply if the Setup.(l)hs is present or not?
As people have said, backwards compat is easy, just include a
Setup.(l)hs that calls defaultMain. If you ommit it, then new
cabal-setup can build it anyway.
Duncan
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
On Tue, 2006-11-28 at 18:28 +, Ross Paterson wrote:
> On Tue, Nov 28, 2006 at 12:28:56AM +0000, Duncan Coutts wrote:
> > It's not clear to me that we need to have an extra field. I had
> > originally envisaged that cabal-setup would just find the right compiler
> > t
gh, since most tools either allow the
locations of all the source files to be specified explicitly, or provide
a search dir feature.
Duncan
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
have to have an
> account on that machine in order to upload packages. The idea behind
> that is to just get something working among folks we already trust.
Yes, it's the simplest thing.
> Something like PAUSE would be good :)
It'd be great to make something better if anyone has the time to do so.
Duncan
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
l would require.
>
> This will also make it easier to do a Yhc port of Cabal.
Actually I fixed that.
The issue was that hugs's version of ReadP needed -98 and Cabal's
'compat' version didn't, so I just changed the ifdefs so that hugs
always uses the compat imp
On Thu, 2006-12-28 at 01:06 +, Ross Paterson wrote:
> On Thu, Dec 28, 2006 at 12:37:07AM +0000, Duncan Coutts wrote:
> > On Wed, 2006-12-27 at 23:22 +, Neil Mitchell wrote:
> > > Another advantage of Parsec is that then you'd be able to install a
> > > Hugs
1 - 100 of 2935 matches
Mail list logo
