On 13/12/12 12:13, Simon Peyton-Jones wrote:
| > We had all these version-skew problems between MSYS and our build
| > system, which we beautifully resolved by including a tar-ball of
| > guaranteed-compatible msys binaries in the GHC source repo (and GHC
| > distributions). The C compiler is there, the linker. Why not
| > autoreconf??
|
| All the build tools are installed separately, we only have the compiler
| tools in the repository.
What "build tools" do you have in mind? Apart from 'autoreconf'?
For example, the in-tree tarball (unpacked to inplace/mingw/bin) includes
gcc
ld
ar
as
cpp
nm
ranlib
strip
What build tools do you expect to use from the user's mingw installation? What
is the downside of including all stuff that suffers version skew (of which
autoreconf is an example), thus removing a road-block? For example, maybe
cygwin's autoreconf behaves slightly differently.
So the reason things are done this way is that you can choose your build
environment between MSYS or Cygwin, but regardless which one of those
you choose we always need the MinGW compiler tools, so we have tarballs
of those in the tree. Historically there were lots of problems with the
build system picking up the wrong bits of MinGW from various places, so
having fixed versions in the tree solves all that.
The tools that come from MSYS or Cygwin include make, autoconf, and of
course the shell and all the shell tools. It might be possible to put
some of these as tarballs in the tree, and maybe that would be a good
idea, though we would have to be careful about mixing Cygwin and MSYS
tools since they use different pathname conventions. Maybe you want to
grab a complete MSYS and put it all in the tree, and forget about
Cygwin. That's a possibility, though I think we hang onto Cygwin
because MSYS can't build the docs properly (I don't remember the details
of this).
It is definitely a version problem you have? I don't remember having
any version difficulties with autoconf for quite a while, since around
version 2.5.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
