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
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
___
| > 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
p
On 02/06/2009 12:31, Claus Reinke wrote:
To summarize, for easier reference:
- configure should warn about build tools with spaces in path
Ian has gone much further than that (great!-) and claims that such
warnings should now be unneccessary for most tools:
http://www.haskell.org/pipermail/cvs-
To summarize, for easier reference:
- configure should warn about build tools with spaces in path
Ian has gone much further than that (great!-) and claims that such
warnings should now be unneccessary for most tools:
http://www.haskell.org/pipermail/cvs-ghc/2009-May/048887.html
- confi
On 29/05/2009 17:34, Claus Reinke wrote:
I've just found some places we were depending on mk/config.mk where we
should have been depending on mk/project.mk. But this won't make any
difference in practice: configure always touches both of them anyway.
If we could prevent configure from touching f
On 29/05/2009 17:34, Claus Reinke wrote:
Note that ghci.ico is in driver/ghci/, not in the directory from which that
command is being run, and ghci.rc tries to refer to it locally (why not
'cd;windres;cd -' ?).
I haven't quite been able to figure out where that command comes from,
and driver/Ma
On 30/05/2009 11:16, Claus Reinke wrote:
windres --preprocessor="c:/mingw/bin/gcc -E -xc -DRC_INVOKED" -o
driver/ghci/ghci.res -i driver/ghci/ghci.rc -O coff
c:\MinGW\bin\windres.exe: can't open icon file `ghci.ico': No such file
or directory
make[1]: *** [driver/ghci/ghci.res] Error 1
make: ***
On Mon, 2009-06-01 at 00:10 +0100, Ian Lynagh wrote:
> On Fri, May 29, 2009 at 03:28:47PM +0100, Claus Reinke wrote:
> >
> > - the build fell over after a long time, when trying to run (note the
> > unprotected spaces)
> >/cygdrive/c/Program Files/MiKTeX 2.7/miktex/bin/dblatex
>
> OK, I've no
On Fri, May 29, 2009 at 03:28:47PM +0100, Claus Reinke wrote:
>
> - the build fell over after a long time, when trying to run (note the
> unprotected spaces)
>/cygdrive/c/Program Files/MiKTeX 2.7/miktex/bin/dblatex
OK, I've now quoted most of the programs we run from make variables, so
tools
Just to check I wasn't talking nonsense about this I just tried building
ghc with the bootstrapping ghc, alex and happy installed in dirs
containing spaces.
I needed to add a few quotes in aclocal.m4 and configure.ac to get
configure to go through and a few more to get the build going. It
eventua
windres --preprocessor="c:/mingw/bin/gcc -E -xc -DRC_INVOKED" -o
driver/ghci/ghci.res -i driver/ghci/ghci.rc -O coff
c:\MinGW\bin\windres.exe: can't open icon file `ghci.ico': No such file
or directory
make[1]: *** [driver/ghci/ghci.res] Error 1
make: *** [all] Error 2
I don't see that error.
On Fri, 2009-05-29 at 15:28 +0100, Claus Reinke wrote:
>I don't recall that ever happening before, so I simply tried again,
>and it didn't repeat. Still, worrying.
>
> - the build fell over after a long time, when trying to run (note the
> unprotected spaces)
> /cygdrive/c/Program Fi
BuildFlavour = perf
This only has an effect if you have the rest of build.mk.sample too. So
if you're quoting the whole of your build.mk here, it won't have any effect.
I was just quoting the differences, the rest is there as well. I also
updated my build.mk from the modified build.mk.sample
On 29/05/2009 15:35, Claus Reinke wrote:
! LaTeX Error: Missing \begin{document}.
See the LaTeX manual or LaTeX Companion for explanation.
Type H for immediate help.
...
l.1 <
?xml version="1.0" encoding="iso-8859-1"?>
?
Since the docs aren't essential (well, not until the rest works;-), I h
On 29/05/2009 15:28, Claus Reinke wrote:
Hoping to try out some recent patches, I had my first experience with
the new build system today (cygwin, building with ghc-6.8.3; did make
maintainer-clean long ago with the old system, then pull and get, etc;
my mk/build.mk has
BuildFlavour = perf
Thi
! LaTeX Error: Missing \begin{document}.
See the LaTeX manual or LaTeX Companion for explanation.
Type H for immediate help.
...
l.1 <
?xml version="1.0" encoding="iso-8859-1"?>
?
Since the docs aren't essential (well, not until the rest works;-), I hit
'q' a few times to get through th
| The standard citation is "Recursive make considered harmful" by Peter Miller:
|
| http://miller.emu.id.au/pmiller/books/rmch/?ref=DDiyet.Com
|
| I should say up front that I'm not completely sure this is going to work
| out, which is one reason we need to try it on a branch. But the approach
| h
Roman Leshchinskiy wrote:
Currently, with recursive make, this means we jump around between
Makefiles a lot, which isn't good for parallelism in the build.
Instead, we want to move all the logic and dependencies into the root
Makefile (or files that get included into it) so that make sees all
Ian,
sorry for the duplicate, forgot to cc the list on my reply.
On 21/11/2008, at 03:58, Ian Lynagh wrote:
We've filled out the new build system design plan with some details:
http://hackage.haskell.org/trac/ghc/wiki/Design/BuildSystem
Thanks for doing this!
There is one thing that I don
Hi,
On Fri, Nov 21, 2008 at 02:58:12AM +0100, Matthias Kilian wrote:
>
> On Thu, Nov 20, 2008 at 04:58:44PM +, Ian Lynagh wrote:
> > We've filled out the new build system design plan with some details:
> > http://hackage.haskell.org/trac/ghc/wiki/Design/BuildSystem
> > Please have a look
Hi,
On Thu, Nov 20, 2008 at 04:58:44PM +, Ian Lynagh wrote:
> We've filled out the new build system design plan with some details:
> http://hackage.haskell.org/trac/ghc/wiki/Design/BuildSystem
> Please have a look and if you forsee any problems, or have any
> suggestions of how things coul
On 14/08/2008, at 18:01, Simon Marlow wrote:
Roman Leshchinskiy wrote:
But that is precisely my (other) point. A lot of that work is
really unnecessary and could be done by Cabal since it only or
mostly depends on the package information. Instead, it is
implemented somewhere in Distributi
On 14/08/2008, at 06:32, Duncan Coutts wrote:
On Wed, 2008-08-13 at 22:47 +1000, Roman Leshchinskiy wrote:
Again, I'm not arguing against a build system written in Haskell. I'd
just like it to be completely separated from Haskell's packaging
system. In particular, "polluting" a package descrip
Roman Leshchinskiy wrote:
But that is precisely my (other) point. A lot of that work is really
unnecessary and could be done by Cabal since it only or mostly depends
on the package information. Instead, it is implemented somewhere in
Distribution.Simple and not really usable from the outside.
On Wed, 2008-08-13 at 22:47 +1000, Roman Leshchinskiy wrote:
> Again, I'm not arguing against a build system written in Haskell. I'd
> just like it to be completely separated from Haskell's packaging
> system. In particular, "polluting" a package description with build
> information seems wr
On 13/08/2008, at 20:34, Simon Marlow wrote:
Roman Leshchinskiy wrote:
Of course there should be a standard build system for simple
packages. It could be part of Cabal or a separate tool (for which
Cabal could, again, act as a preprocessor).
GHC is a special case: we already need a build sy
On Wed, 2008-08-13 at 11:34 +0100, Simon Marlow wrote:
> Cabal has two parts: some generic infrastructure, and a "simple" build
> system (under Distribution.Simple) that suffices for most packages. We
> distribute them together only because it's convenient; you don't have to
> use the simple b
Ian Lynagh wrote:
On Tue, Aug 12, 2008 at 11:11:38AM +0100, Simon Marlow wrote:
I propose we do this:
- Extract the code from Cabal that generates Makefiles, and treat it as
part of the GHC build system. Rather than generating a Makefile
complete with build rules, we generate a Makefile
Roman Leshchinskiy wrote:
Of course there should be a standard build system for simple packages.
It could be part of Cabal or a separate tool (for which Cabal could,
again, act as a preprocessor).
GHC is a special case: we already need a build system for other reasons.
I agree. I just don'
On 13/08/2008, at 17:47, Simon Marlow wrote:
Roman Leshchinskiy wrote:
On 12/08/2008, at 20:11, Simon Marlow wrote:
- Extract the code from Cabal that generates Makefiles, and treat
it as
part of the GHC build system. Rather than generating a Makefile
complete with build rules, we generat
Roman Leshchinskiy wrote:
On 12/08/2008, at 20:11, Simon Marlow wrote:
- Extract the code from Cabal that generates Makefiles, and treat it as
part of the GHC build system. Rather than generating a Makefile
complete with build rules, we generate a Makefile that just
has the package-speci
On 12/08/2008, at 20:11, Simon Marlow wrote:
- Extract the code from Cabal that generates Makefiles, and treat it
as
part of the GHC build system. Rather than generating a Makefile
complete with build rules, we generate a Makefile that just
has the package-specific metadata (list of mod
Duncan Coutts:
On Tue, 2008-08-12 at 11:11 +0100, Simon Marlow wrote:
I propose we do this:
- Extract the code from Cabal that generates Makefiles, and treat
it as
part of the GHC build system. Rather than generating a Makefile
complete with build rules, we generate a Makefile that
On Tue, Aug 12, 2008 at 11:11:38AM +0100, Simon Marlow wrote:
>
> I propose we do this:
>
> - Extract the code from Cabal that generates Makefiles, and treat it as
>part of the GHC build system. Rather than generating a Makefile
>complete with build rules, we generate a Makefile that ju
> Simon PJ and I had a talk about the build system earlier today, I thought
> I'd float the idea we discussed...
> I propose we do this:
>
> - Extract the code from Cabal that generates Makefiles, and treat it as
> part of the GHC build system. Rather than generating a Makefile
>
Malcolm Wallace wrote:
Simon Marlow <[EMAIL PROTECTED]> wrote:
This means we still get to use 'make', we still get to use the .cabal
files as metadata, but the build system is more private to GHC, more
extensible, and hopefully more understandable and modifiable.
This is essentially the sam
Simon Marlow <[EMAIL PROTECTED]> wrote:
> This means we still get to use 'make', we still get to use the .cabal
> files as metadata, but the build system is more private to GHC, more
> extensible, and hopefully more understandable and modifiable.
This is essentially the same approach that nhc98
On Tue, 2008-08-12 at 11:11 +0100, Simon Marlow wrote:
> I propose we do this:
>
> - Extract the code from Cabal that generates Makefiles, and treat it as
> part of the GHC build system. Rather than generating a Makefile
> complete with build rules, we generate a Makefile that just
>
Now merged into the HEAD.
great, thanks! on my win/xp setup (cygwin tools, mingw gcc),
sh boot
./configure --host=i386-unknown-mingw32
make
make binary-dist
seems to produce a useable ghci.exe again, with ghc-pkg.exe
showing a more healthy listing as well.
some issues:-)
- exec
On Sat, Jun 09, 2007 at 04:24:52PM +0100, Ian Lynagh wrote:
>
> http://darcs.haskell.org/ghc-build-system/
Now merged into the HEAD.
Thanks
Ian
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
45 matches
Mail list logo
