It is confusing, though, that Cabal silently uses compiler/parser/Parser.hs,
if it is meant to generate and use compiler/dist-stage[12]/Parser.hs.
There should be a Cabal warning:
"variant of generated file in source dir, using that instead of generated file".
As far as I know, if you've got c
On Tue, 2008-08-05 at 16:15 +0100, Claus Reinke wrote:
> >>> It is confusing, though, that Cabal silently uses
> >>> compiler/parser/Parser.hs,
> >>> if it is meant to generate and use compiler/dist-stage[12]/Parser.hs.
> >>>
> >>> There should be a Cabal warning:
> >>> "variant of generated file
On Tue, 2008-08-05 at 22:11 +1000, Roman Leshchinskiy wrote:
> On 05/08/2008, at 21:15, Duncan Coutts wrote:
>
> > It knows that .y can be pre-processed to .hs so if it finds both .hs
> > and .y then it knows that .y is the ultimate source file and
> > pre-processes that.
> >
> > Do you think this
It is confusing, though, that Cabal silently uses compiler/parser/Parser.hs,
if it is meant to generate and use compiler/dist-stage[12]/Parser.hs.
There should be a Cabal warning:
"variant of generated file in source dir, using that instead of generated file".
As far as I know, if you've got c
On 05/08/2008, at 21:15, Duncan Coutts wrote:
It knows that .y can be pre-processed to .hs so if it finds both .hs
and .y then it knows that .y is the ultimate source file and
pre-processes that.
Do you think this is the wrong behaviour or are you observing
different
behaviour?
I think I'
On Tue, Aug 05, 2008 at 09:42:19AM +0100, Simon Marlow wrote:
>
> Ian: I suspect this is now broken. So we could either require Happy and
> Alex unconditionally, in which case the wiki docs need to be updated, or we
> could restore the previous behaviuor, but I'm guessing that's harder.
In the
On Tue, 2008-08-05 at 14:51 +1000, Roman Leshchinskiy wrote:
> On 05/08/2008, at 14:15, Judah Jacobson wrote:
>
> > It seems that the old, pre-Cabal build system did not clean some or
> > all of the preprocessed files (such as Parser.hs). This was not much
> > of a problem in practice, because th
On Tue, 2008-08-05 at 10:30 +0100, Claus Reinke wrote:
> > contrast, Cabal stores all generated files in a separate directory
> > (compiler/dist-stage[1/2]), and thus doesn't need to look at relative
> > timestamps; so it gets confused by the old, leftover Parser.hs et al.
>
> While that is cleane
contrast, Cabal stores all generated files in a separate directory
(compiler/dist-stage[1/2]), and thus doesn't need to look at relative
timestamps; so it gets confused by the old, leftover Parser.hs et al.
While that is cleaner, it also takes some getting used to, as generated
sources are no lo
Max Bolingbroke wrote:
Packages that explicitly depend on base-3.x will continue to work.
Unfortunately these are few and far between, despite our warnings after the
6.8 release.
If this was reccomended practice, then I must have missed where it was
documented. In particular, the "Upgrading pac
> Packages that explicitly depend on base-3.x will continue to work.
> Unfortunately these are few and far between, despite our warnings after the
> 6.8 release.
If this was reccomended practice, then I must have missed where it was
documented. In particular, the "Upgrading packages to work with r
On 05/08/2008, at 18:30, Thomas Schilling wrote:
How is that better than having only the actual source files in you
src directory? All generated files will go into dist-*/ and there's
no way to confuse anything. Cabal does allow including pre-
generated files in dist tarballs, but for deve
Claus Reinke wrote:
Btw, are the exception changes meant to lead to another round
of library breakage/updates, or is this just the compatibility mode
not yet being in place?
We're planning to have some backwards compatibility in place for the 6.10.1
release (maybe I'd get a chance to work on
Judah Jacobson wrote:
It seems that the old, pre-Cabal build system did not clean some or
all of the preprocessed files (such as Parser.hs).
Actually this was by design. 'make distclean' is supposed to clean
everything that is not shipped in a source distribution, and source
distributions a
How is that better than having only the actual source files in you
src directory? All generated files will go into dist-*/ and there's
no way to confuse anything. Cabal does allow including pre-generated
files in dist tarballs, but for development, generated files have
intentionally be mo
It seems that the old, pre-Cabal build system did not clean some or
all of the preprocessed files (such as Parser.hs). This was not much
of a problem in practice, because the Makefiles used the relative
timestamps to tell whether to regenerate Parser.hs from Parser.y. In
contrast, Cabal stores a
On 05/08/2008, at 14:15, Judah Jacobson wrote:
It seems that the old, pre-Cabal build system did not clean some or
all of the preprocessed files (such as Parser.hs). This was not much
of a problem in practice, because the Makefiles used the relative
timestamps to tell whether to regenerate Par
On Mon, Aug 4, 2008 at 12:07 PM, Claus Reinke <[EMAIL PROTECTED]> wrote:
> make distclean; ./darcs-all pull -a; sh boot; ./configure ..; make
>
> first complained about
>
> parser/Parser.hs:14:36:
>
> Module `HscTypes' does not export `DeprecTxt'
>
> Since Parser.hs and Parser.y looked diff
Another 'make distclean' removes Parser.hs, but leaves lots of other
.hs files that have .x or .y files:
$ ls compiler/parser/
Ctype.lhs HaddockLex.x HaddockUtils.hs Lexer.xParserCore.y
cutils.c
HaddockLex.hs HaddockParse.hs LexCore.hs Parser.y.pp
make distclean; ./darcs-all pull -a; sh boot; ./configure ..; make
first complained about
parser/Parser.hs:14:36:
Module `HscTypes' does not export `DeprecTxt'
Since Parser.hs and Parser.y looked different, I removed the former
and tried again. But now, I get
dist-stage1/build/Parse
20 matches
Mail list logo
