agh
Date: Fri Nov 30 12:07:07 2012 +
Remove unused PYTHON in build system
>---
configure.ac|4
mk/config.mk.in |1 -
2 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/configure.ac b/configure.ac
agh
Date: Thu Nov 29 23:52:07 2012 +
libffi build system tweaks
>---
compiler/ghc.mk |3 +++
configure.ac|2 +-
ghc.mk |8 +---
libffi/ghc.mk |1 +
rts/ghc.mk |5 -
5 files chang
On 22/11/2012 19:38, Ian Lynagh wrote:
On Wed, Nov 21, 2012 at 02:28:24PM -0500, Ben Gamari wrote:
Any thoughts about what might be going on with any of the above?
FWIW, I think that some of your problems probably stem from using an old
cabal-install compiled against an old Cabal, which assum
On Wed, Nov 21, 2012 at 02:28:24PM -0500, Ben Gamari wrote:
>
> Any thoughts about what might be going on with any of the above?
FWIW, I think that some of your problems probably stem from using an old
cabal-install compiled against an old Cabal, which assumes that -static
is the default and so d
Currently it seems that master's build system has a few sticky points,
* build.mk.sample adds dyn to GhcLibWays twice in the perf and
perf-llvm flavors (added once in the global DYNAMIC_BY_DEFAULT check
and again in the per-flavor PlatformSupportsSharedLibs). This leads
to a mult
agh
Date: Thu Oct 25 18:06:15 2012 +0100
Fix the haddocking build system rules when dynamic is the default way
>---
ghc.mk |2 ++
rules/haddock.mk |6 +++---
2 files changed, 5 insertions(+), 3 deletions(-)
diff
agh
Date: Tue Oct 16 01:25:45 2012 +0100
Build system fix for building a profiling GHC
>---
ghc.mk |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/ghc.mk b/ghc.mk
index 2c64b02..aa700a6 100644
--- a/
low
Date: Fri Oct 5 10:34:42 2012 +0100
Fix a dependency bug in the build system
I've been meaning to track this one down for a long time.
Occasionally a build will fail with an error about a .so library being
truncated; the reason was that we weren't tracking the de
agh
Date: Wed Oct 3 16:17:35 2012 +0100
Follow change in GHC build system
>---
ghc.mk |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/ghc.mk b/ghc.mk
index bca7b9b..ab57961 100644
--- a/ghc.mk
+++ b/
agh
Date: Wed Oct 3 16:17:05 2012 +0100
Follow change in GHC build system
>---
ghc.mk |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/ghc.mk b/ghc.mk
index 5076c6f..70284a4 100644
--- a/ghc.mk
+++ b/
agh
Date: Thu Sep 27 02:00:57 2012 +0100
Follow changes in GHC build system
>---
ghc.mk |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/ghc.mk b/ghc.mk
index 3742565..bca7b9b 100644
--- a/ghc.mk
agh
Date: Thu Sep 27 02:00:19 2012 +0100
Follow changes in ghc build system
>---
ghc.mk |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/ghc.mk b/ghc.mk
index 0a104c1..5076c6f 100644
--- a/ghc.mk
agh
Date: Thu Sep 27 01:57:19 2012 +0100
Tweak the build system handling of shell wrappers
Rather than having a separate
foo_INSTALL_SHELL_WRAPPER
variable, we just use
foo_INSTALL && foo_SH
agh
Date: Thu Sep 27 01:50:53 2012 +0100
Remove a stray " in the build system
>---
rules/build-prog.mk |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/rules/build-prog.mk b/rules/build-prog.mk
in
I'm in support of the change, should be nice for us human builders.
On 1 May 2012 22:38, Ian Lynagh wrote:
> On Tue, May 01, 2012 at 09:28:32AM +0100, Simon Marlow wrote:
>> >
>> > To get the traditional fully verbose output, set V=1, like this:
>> >
>> > make V=1
>>
>> I'd be ok to m
On Tue, May 01, 2012 at 09:28:32AM +0100, Simon Marlow wrote:
> >
> > To get the traditional fully verbose output, set V=1, like this:
> >
> > make V=1
>
> I'd be ok to merge this branch in. Does anyone have any concerns?
I don't mind, as long as the nightly builds all set V=1 so tha
d209588a40928e21a253bc9341689b5174c00cfc
Author: Iavor S. Diatchki
Date: Fri Apr 27 13:24:05 2012 -0700
A build-system tweak for more readable build output.
This change reduces the (default) verbosity of the build system.
This makes it easier to spot warnings in the output and, also, it
r S. Diatchki
Date: Fri Apr 27 13:24:05 2012 -0700
A build-system tweak for more readable build output.
This change reduces the (default) verbosity of the build system.
This makes it easier to spot warnings in the output and, also, it
makes it easier to estimate how far al
low
Date: Wed Feb 8 15:49:50 2012 +
a build system fix that is already on HEAD
>---
mk/compiler-ghc.mk |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/mk/compiler-ghc.mk b/mk/compiler-ghc.mk
index 4
agh
Date: Sat Nov 19 01:33:21 2011 +
Follow GHC build system change to the way we call rm
>---
ghc.mk |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/ghc.mk b/ghc.mk
index 12335fb..3742565
agh
Date: Sat Nov 19 01:29:05 2011 +
Improve the way we call "rm" in the build system; fixes trac #4916
We avoid calling "rm -rf" with no file arguments; this fixes cleaning
on Solaris, where that fails.
We also check for suspicious argumen
ier
Date: Fri Nov 11 17:37:14 2011 +1100
Build system wibbles for new dph-lifted-vseg library
The old dph-par and dph-seq CPP libraries are gone. The DPH front end
libraries are now dph-lifted-*, and are only built in one
ier
Date: Sat Nov 12 15:54:23 2011 +1100
build system: set dph-lifted-base to be a dph package
>---
ghc.mk |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/ghc.mk b/ghc.mk
index b076cc0..2d8aaf4 100644
11 10:31, austin seipp wrote:
>>
>> Okay, so I took a stab at the build system and getting the analysis
>> plugin at least building, and the results are in this commit:
>>
>>
>> https://github.com/thoughtpolice/ghc/commit/c30b32fc98a78e322d872b82bed670ee4627ecf0
>&
On 04/10/2011 10:31, austin seipp wrote:
Okay, so I took a stab at the build system and getting the analysis
plugin at least building, and the results are in this commit:
https://github.com/thoughtpolice/ghc/commit/c30b32fc98a78e322d872b82bed670ee4627ecf0
I'm working on pushing a version
low
Date: Mon Oct 3 16:45:05 2011 +0100
Build system commentary
Add documentation describing all the variables that contain options
for Haskell compilations, what they mean and where they are (or can
be) defined.
In due course we should expand this to cover all the bu
Okay, so I took a stab at the build system and getting the analysis
plugin at least building, and the results are in this commit:
https://github.com/thoughtpolice/ghc/commit/c30b32fc98a78e322d872b82bed670ee4627ecf0
I'm working on pushing a version that moves most of the logic in this
c
agh
Date: Thu Jul 28 16:39:45 2011 +0100
GHC build system: Don't install the datafiles twice
>---
ghc.mk |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/ghc.mk b/ghc.mk
index 158baee..7e9
On Thu, Jul 21, 2011 at 11:20 AM, Johan Tibell wrote:
> After having spent about 8 hours trying to add a new static library as
> a dependency of ghc-prim I feel with you. I've read all the wiki
> pages, make -p:ed myself to death, tried to imitate other files, read
> through examples, read through
Hi all,
On Thu, May 12, 2011 at 8:58 AM, Ben Lippmeier wrote:
> Hi All,
> I thought I'd take a moment to mention that the GHC build system is basically
> unmaintainable by anyone except the original authors. It's clear that a
> heroic effort has been made to fit a square
agh
Date: Thu Jun 23 18:36:51 2011 +0100
Follow Cabal reorganisation, and improve build system a little
>---
boot |1 +
ghc.mk | 23 ++-
ghc/ghc.mk |1 +
sed as the initial bootstrap. It's
>> not been done before, but I see no reason it won't work.
>>
>> Yhc died because of build system choice, but I'm sure that won't
>> happen to GHC - it will just suck away fun and valuable Haskell
>> hacking time.
On Mon, May 16, 2011 at 11:08:33AM +0100, Simon Marlow wrote:
>
> Perhaps make's scheduling algorithm is suboptimal for our graph. I
> seem to recall Shake does some kind of random scheduling, is that
> right?
I don't know if shake does so, but a build system could remembe
strap. It's
not been done before, but I see no reason it won't work.
I hate working on build systems as much as the next person, but I'm also
conscious of the fact that the YHC basically died under the weight of its
broken build system. I don't think that'll happen with
done before, but I see no reason it won't work.
> I hate working on build systems as much as the next person, but I'm also
> conscious of the fact that the YHC basically died under the weight of its
> broken build system. I don't think that'll happen with GHC, but
On Thu, May 12, 2011 at 09:46:30PM +1000, Ben Lippmeier wrote:
>
> Thanks for the pointers. Another difficulty is that all the rules go into a
> single global namespace, so understanding the interaction is hard, at least
> for me. There's not much in the way of module structure to help get your
On 12/05/2011, at 9:23 PM, Simon Marlow wrote:
> On 12/05/2011 07:58, Ben Lippmeier wrote:
>> Hi All,
>> I thought I'd take a moment to mention that the GHC build system is
>> basically unmaintainable by anyone except the original authors.
> One day maybe
On 12/05/2011 07:58, Ben Lippmeier wrote:
Hi All,
I thought I'd take a moment to mention that the GHC build system is basically
unmaintainable by anyone except the original authors. It's clear that a heroic
effort has been made to fit a square peg into a round hole, and I *want* to
Hi All,
I thought I'd take a moment to mention that the GHC build system is basically
unmaintainable by anyone except the original authors. It's clear that a heroic
effort has been made to fit a square peg into a round hole, and I *want* to
help, but stuff like this makes my
agh
Date: Fri Apr 29 14:37:44 2011 +0100
Add stage-specific AS variables to the build system
>---
mk/config.mk.in |5 +
rules/c-suffix-rules.mk |2 +-
rules/package-config.mk |1 +
3 files changed, 7 inse
agh
Date: Wed Apr 27 00:19:09 2011 +0100
Build system: Tell hsc2hs where to find cabal_macros.h
>---
rules/distdir-way-opts.mk |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/rules/distdir-way-opts.mk b
Hi folks,
If after pulling the latest patches your stage2 compiler starts
segfaulting, it might be due to this:
http://hackage.haskell.org/trac/ghc/ticket/5109
the build system isn't rebuilding enough stuff after changes to the RTS.
Ian is fixing it, but until then it might be nece
Thu Jan 13 07:50:23 PST 2011 simo...@microsoft.com
* Add OSTYPE build-system variable, and use it
The use is in install.mk.in, where we need to know when
we're on Cygwin.
This fixes the build on my Windows box, where I have
both Msys and Cygwin.
M ./configure.ac +5
M
Sat Mar 5 06:48:25 PST 2011 Ian Lynagh
* Avoid some shell calls in the build system
The DEP_INCLUDE_DIRS and DEP_LIB_DIRS variables always contain
single-quote dirs, so we can use e.g.
$(subst $(space)',$(space)-L',$(space)$($1_$2_DEP_LIB_DIRS_SINGLE_QUOTED))
to add
agh
Date: Mon Feb 7 14:20:46 2011 +
Call the final build system phase "final" rather than ""
>---
Makefile |2 +-
docs/man/ghc.mk|2 +-
ghc.mk |8 ++
Mon Feb 7 06:20:46 PST 2011 Ian Lynagh
* Call the final build system phase "final" rather than ""
M ./Makefile -1 +1
M ./docs/man/ghc.mk -1 +1
M ./ghc.mk -2 +6
M ./rules/build-package.mk -2 +2
M ./rules/build-prog.mk -2 +2
M ./rules/docbook.mk -3 +
Ah, thank you so much!
| -Original Message-
| From: cvs-ghc-boun...@haskell.org [mailto:cvs-ghc-boun...@haskell.org] On
| Behalf Of Ian Lynagh
| Sent: 27 January 2011 00:23
| To: cvs-ghc@haskell.org
| Subject: Re: build system
|
| On Tue, Jan 25, 2011 at 11:37:18AM +, Simon Peyton
On Tue, Jan 25, 2011 at 11:37:18AM +, Simon Peyton-Jones wrote:
>
> In compiler/, if I say "make 1", it rebuilds the stage1 compiler, AND THEN
> RE-CONFIGURES all the libraries. The latter takes ages.
Sorry, should be fixed now.
Thanks
Ian
___
Wed Jan 26 16:17:39 PST 2011 Ian Lynagh
* Fix "make 1" etc following the build system changes
The logic is now in mk/compiler-ghc.mk rather than being duplicated in
ghc/Makefile and compiler/Makefile.
M ./Makefile +2
M ./compiler/Makefile -25 +2
M ./ghc/Makefile -4
Ian
In compiler/, if I say "make 1", it rebuilds the stage1 compiler, AND THEN
RE-CONFIGURES all the libraries. The latter takes ages.
The whole point of 'make 1' is to make the stage1 compiler only, without the
knock on effects. As it now stands, it takes 5 seconds to rebuild the compiler
(
Sun Jan 23 07:14:08 PST 2011 Ian Lynagh
* Add build system profiling to build system
M ./ghc.mk +1
M ./rules/build-dependencies.mk +2
M ./rules/build-package-data.mk +2
M ./rules/build-package-way.mk +2
M ./rules/build-package.mk +2
M ./rules/build-perl.mk +2
M
Sat Jan 22 11:09:28 PST 2011 Ian Lynagh
* Simplify the build system, and remove 2 phases
From
http://hackage.haskell.org/trac/ghc/wiki/Building/Architecture/Idiom/PhaseOrdering
Phase 0:
Includes: package-data.mk files for things built by the
bootstrapping
Thu Jan 13 07:50:23 PST 2011 simo...@microsoft.com
* Add OSTYPE build-system variable, and use it
The use is in install.mk.in, where we need to know when
we're on Cygwin.
This fixes the build on my Windows box, where I have
both Msys and Cygwin.
M ./configure.ac +5
M
Sat Jan 15 18:00:35 PST 2011 Ian Lynagh
* Simplify, and future-proof, a dependency in the build system
M ./ghc.mk -5 +1
View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc;a=darcs_commitdiff;h=20110116020035-3fd76-8c37d539932dd2860db0d7179d6a2ecac5ba8978.gz
Sat Jan 15 15:19:27 PST 2011 Ian Lynagh
* Build system improvements
We no longer use dummy-ghc; instead we don't configure most packages
until the stage1 compiler is available.
We also now use Cabal for building the ghc-bin package.
There are a couple more sanity check
Sun Nov 14 05:46:36 PST 2010 Ian Lynagh
* Build system tweak: Inline DQ now it's the same on all platforms
M ./rts/ghc.mk -20 +17
View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc-7.0/ghc;a=darcs_commitdiff;h=20101114134636-
Sun Nov 14 06:03:11 PST 2010 Ian Lynagh
* Add a build system dependency; fixes #4357
M ./rules/build-dependencies.mk +3
View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc-7.0/ghc;a=darcs_commitdiff;h=20101114140311-3fd76-418bca9888a0cd6c16e0e50241ddb36c44e994d0.gz
Sun Nov 14 05:46:36 PST 2010 Ian Lynagh
* Build system tweak: Inline DQ now it's the same on all platforms
M ./rts/ghc.mk -20 +17
View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc;a=darcs_commitdiff;h=20101114134636-3fd76-cc174596c59fc503ebefbcbec4130bfcd4a860
Sun Nov 14 06:03:11 PST 2010 Ian Lynagh
* Add a build system dependency; fixes #4357
M ./rules/build-dependencies.mk +3
View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc;a=darcs_commitdiff;h=20101114140311-3fd76-418bca9888a0cd6c16e0e50241ddb36c44e994d0.gz
Thu Sep 23 02:56:42 PDT 2010 Simon Marlow
* Refactoring and tidy up in the build system
Instead of the ghc-stage and ghc-stage2-package files in a package, we
now have a list of these in ghc.mk. There are other similar lists (of
boot-packages and non-installable packages), so this is
Thu Sep 23 02:56:42 PDT 2010 Simon Marlow
* Refactoring and tidy up in the build system
Instead of the ghc-stage and ghc-stage2-package files in a package, we
now have a list of these in ghc.mk. There are other similar lists (of
boot-packages and non-installable packages), so this is
Tue Sep 21 06:47:29 PDT 2010 Simon Marlow
* add a simple trace facility to the build system
saying
make TRACE=1
prints most of the macro calls and their arguments. It's easy to
trace new macros; see rules/trace.mk.
M ./ghc.mk +1
M ./rules/build-dependencies.
Tue Sep 21 06:47:29 PDT 2010 Simon Marlow
* add a simple trace facility to the build system
saying
make TRACE=1
prints most of the macro calls and their arguments. It's easy to
trace new macros; see rules/trace.mk.
M ./ghc.mk +1
M ./rules/build-dependencies.
Thu Aug 5 08:53:19 PDT 2010 Ian Lynagh
* Fix the HsColour test in the build system
M ./mk/config.mk.in -1 +1
View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc;a=darcs_commitdiff;h=20100805155319-3fd76-592a0c8516edb3a1d90c72ff13e1e30374906812.gz
Fri Jul 9 15:45:34 PDT 2010 Ian Lynagh
* Move a bit of build system code
M ./ghc.mk -12 +12
View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc;a=darcs_commitdiff;h=20100709224534-3fd76-fe982bfe03b50880ed0f444b770d0044b843cbc9.gz
| > It used to be the case that one could say 'make show VALUE=GhcStage1HcOpts'
| to see the value of that variable. But not now. See below. It still works
| in the root directory.
|
| Fixed.
Thanks!
| > Moreover 'make tags' doesn't seem to work any more (anywhere). It seems to
| just try to
Hi Simon,
On Wed, Jun 16, 2010 at 12:09:10PM +, Simon Peyton-Jones wrote:
>
> It used to be the case that one could say 'make show VALUE=GhcStage1HcOpts'
> to see the value of that variable. But not now. See below. It still works
> in the root directory.
Fixed.
> Moreover 'make tags' d
On 16/06/2010 13:09, Simon Peyton-Jones wrote:
Ian
It used to be the case that one could say ‘make show
VALUE=GhcStage1HcOpts’ to see the value of that variable. But not now.
See below. It still works in the root directory.
Since the new build system it now only works at the root. We could
Ian
It used to be the case that one could say 'make show VALUE=GhcStage1HcOpts' to
see the value of that variable. But not now. See below. It still works in the
root directory.
Moreover 'make tags' doesn't seem to work any more (anywhere). It seems to
just try to build the compiler. (Which
Tue May 18 06:15:28 PDT 2010 Ian Lynagh
* Define RM_OPTS_REC in the 6.12 branch build system
M ./mk/tree.mk +1
View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc-6.12/ghc;a=darcs_commitdiff;h=20100518131528-3fd76-18d2a7a270a08d2cccf66b4efd0d3f4b460fa9c3.gz
Sat May 8 04:57:45 PDT 2010 Ian Lynagh
* Tidy up the "rm" flags in the build system
M ./ghc.mk -12 +12
M ./libffi/ghc.mk -1 +1
M ./mk/tree.mk +1
M ./rules/build-package.mk -1 +1
M ./rules/clean-target.mk -1 +1
M ./rules/docbook.mk -1 +1
M ./utils/mkdirh
Tue May 4 15:50:35 PDT 2010 Ian Lynagh
* In build system, call package-config after including package data
Otherwise the $1_$2_HC_OPTS variable gets clobbered.
M ./rules/build-package.mk -2 +2
M ./rules/build-prog.mk -2 +2
View patch online:
http://darcs.haskell.org/cgi-bin
Sun Mar 21 09:19:09 PDT 2010 Ian Lynagh
* Add the external core PDF to the new build system
M ./docs/ext-core/Makefile -61 +2
A ./docs/ext-core/ghc.mk
M ./docs/users_guide/using.xml -1 +1
M ./ghc.mk +1
M ./mk/config.mk.in +2
Sun Mar 21 09:19:09 PDT 2010 Ian Lynagh
* Add the external core PDF to the new build system
M ./docs/ext-core/Makefile -61 +2
A ./docs/ext-core/ghc.mk
M ./docs/users_guide/using.xml -1 +1
M ./ghc.mk +1
M ./mk/config.mk.in +2
Neil,
I hope I can count on your continued support. Your comments are hoping me
refine my thinking. What I am attempting to do is ambitious and so I have my
work cut out for me.
Do I really need quasi-quotes? In a sense I will and in another I won't.
That is the best way to describe it. Ther
Dear Neil,
Neil: For GHC in particular, they currently have a build system that works,
what's the benefit of changing the build system?
John:
To make it even better. As I pointed out in my GHC ticket system feature
request ticket (http://hackage.haskell.org/trac/ghc/ticket/3912) the
I'm in the process of preparing a rather long letter. In short my response
is "Fair enough. I'll take that as a challenge." This letter is a
meta-discussion. I'm talking about what I'm talking about. I thought to
flush out some of my thoughts and respond to objections which I more than
happy to
On 05/03/10 19:28, John D. Earle wrote:
My ticket was just closed with a won't fix resolution. The comment was
"I think the first step would be to create a build system tool, and then
we can look at whether it makes sense to use it for GHC." On the face of
it seems some what
> rebuilds - anything less than a second on a null rebuild isn't
>> relevant.
>
> Yes, the first part of the article is hideous. But I liked the idea
> of updating the meta information in the background. I don't think
> that is very portable or even needed for most kinds
ts, but
it is something to keep in mind in, that this is something a build
system might want to support one day.
>>> Dependencies among files I anticipate could be treated as a type.
>
> I'd be very surprised if that was possible.
N
Hi,
As Simon says, I've got some experience using Haskell for writing
build scripts. I had a fork of the Yhc build script written in
Haskell, for example. I think it's a very good idea in general. For
GHC in particular, they currently have a build system that works,
what's the bene
As it concerns sources of inspiration is how proof assistants with dependent
types implement their module system. Traditionally, a computer programming
language consists of more than one sublanguage. A language of expressions and a
module language for example. With dependent types it becomes pos
The follow may seem a little like science fiction, but taken to its limit I do
not find it difficult to envision a single massive data stream greater than a
terabyte that consists of the entire software repository of say a corporation
or government and feeding it to the compiler that would globa
When the stream length (file size) is only a few kilobytes applying
optimizations to speed the compilation process along isn't especially
meaningful. With massive stream lengths there is economy of scale that will
likely also translate to producing better machine code and other aspects of the
p
The timing for this is good in that new technologies are coming forward that
may render the disk operating system paradigm altogether obsolete and not
merely grossly inefficient. Moving to a new paradigm now may help position us
ahead of the curve.___
e gusto.
Achim Schneider wrote "This may be fairly easy, if the generated script does
not have to come with major build-system capabilities: Leaving out most of
dependency
analysis and support -- at the utmost -- restarting a failed build from
the rule whose source file has last recentl
cmake. Once the build system is encoded in Haskell it will be possible to
emit shell scripts and make files as intermediate languages. It would be a
way of having your cake and eating it too. There is also just focusing our
attention on ensuring that we get cross compilation right. We could
On Fri, Mar 05, 2010 at 09:26:08PM +, Simon Marlow wrote:
> >Switching GHC to a completely new build system written completely
> >in Haskell would be the most stupid idea ever. (You know why)
>
> You're referring to bootstrapping, I presume?
Yes.
> I did think
On 05/03/10 21:17, Matthias Kilian wrote:
On Fri, Mar 05, 2010 at 12:17:55PM +, Simon Marlow wrote:
I suggest that the way to start would be to design and build the
infrastructure first, and then think about replacing GHC's build system.
I have to admit, having rewritten GHC&#x
On Fri, Mar 05, 2010 at 12:17:55PM +, Simon Marlow wrote:
> I suggest that the way to start would be to design and build the
> infrastructure first, and then think about replacing GHC's build system.
> I have to admit, having rewritten GHC's build system less than a y
My ticket was just closed with a won't fix resolution. The comment was "I
think the first step would be to create a build system tool, and then we can
look at whether it makes sense to use it for GHC." On the face of it seems
some what logical. It is certainly non-committ
Simon Marlow wrote "I suggest that the way to start would be to design and
build the
infrastructure first, and then think about replacing GHC's build system."
Simon Marlow wrote "But if someone else were to do the work, and the result was
maintainable and has at least th
/ticket/3912 entitled "Gut Build System".
> I suppose the title is to the point.
>
> I believe that considerable advantage can be achieved by positioning the GHC
> Haskell language so that it may be used as a viable alternative to shell
> scripts and make files. Using Haskel
On 04/03/2010 21:06, John D. Earle wrote:
Hello,
I wish to discuss my feature request
http://hackage.haskell.org/trac/ghc/ticket/3912 entitled "Gut Build
System". I suppose the title is to the point.
I believe that considerable advantage can be achieved by positioning the
GHC Haskell l
Hello,
I wish to discuss my feature request
http://hackage.haskell.org/trac/ghc/ticket/3912 entitled "Gut Build System". I
suppose the title is to the point.
I believe that considerable advantage can be achieved by positioning the GHC
Haskell language so that it may be used a
On Thu, Feb 25, 2010 at 09:24:59AM +, Tristan Allwood wrote:
> +1 for having separate 'make tags' and 'make TAGS'.
Done.
Thanks
Ian
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
On 25/02/2010 09:14, Simon Peyton-Jones wrote:
|> good point. Could we call them 'tags-emacs' and 'tags-vim'?
|
| We could do, but tags and TAGS are the standard names.
|
| We could also have separate "make tags" and "make TAGS" commands, which
| generate only the named file.
|
| Whatever the d
+1 for having separate 'make tags' and 'make TAGS'.
Cheers,
Tris
On Thu, Feb 25, 2010 at 09:14:46AM +, Simon Peyton-Jones wrote:
> | > good point. Could we call them 'tags-emacs' and 'tags-vim'?
> |
> | We could do, but tags and TAGS are the standard names.
> |
> | We could also have sep
| > good point. Could we call them 'tags-emacs' and 'tags-vim'?
|
| We could do, but tags and TAGS are the standard names.
|
| We could also have separate "make tags" and "make TAGS" commands, which
| generate only the named file.
|
| Whatever the decision, implementing it will be easy.
|
Doe
On Wed, Feb 24, 2010 at 04:26:23PM +, Simon Peyton-Jones wrote:
> | > tags is the vim equivalent of TAGS.
> |
> | Unfortunately, on a case-insensitive filesystem, such as the defaults
> | on Windows and MacOS, there is no way to have both a 'tags' and a
> | 'TAGS' file.
>
> good point. Could
1 - 100 of 247 matches
Mail list logo
