Peter Tanski wrote:
I keep on referring to this as temporary because there are two different
builds here:
(1) the build using the old mingw-GHC, without option support for CL; and,
(2) the build using the new Windows-native GHC.
Yes. And what I'm suggesting is the following - what I've been
On Jun 26, 2007, at 4:59 AM, Simon Marlow wrote:
Peter Tanski wrote:
I keep on referring to this as temporary because there are two
different builds here:
(1) the build using the old mingw-GHC, without option support for
CL; and,
(2) the build using the new Windows-native GHC.
Yes. And
Peter Tanski wrote:
On Jun 22, 2007, at 11:42 AM, Simon Marlow wrote:
Peter Tanski wrote:
A bit invasive (it involves modifying the make rules so they take an
object-suffix variable). Instead of the current suffix.mk:
$(odir_)%.$(way_)o : %.hc
it should be:
$(odir_)%.$(way_)$(obj_sfx) :
On Jun 25, 2007, at 5:19 AM, Simon Marlow wrote:
Yes it is easy but now all Makefiles must be changed to use $
(osuf), such as this line in rts/Makefile:
378: %.$(way_)o : %.cmm $(H_FILES),
for what will be a (hopefully) temporary Windows build.
I bet there are only a few makefiles that
On Mon, 2007-06-25 at 11:43 -0400, Peter Tanski wrote:
It would be much better to have a single build system. I would
gladly replace the whole thing for three reasons:
(1) it is a source of many build bugs and it makes them much more
difficult to track down; and,
(2) it seems to be a
On Tue, 26 Jun 2007 02:06:25 +1000
skaller [EMAIL PROTECTED] wrote:
My basic idea is that it should be generic and package based,
that is, it does NOT include special purpose tools as might
be required to build, say, Haskell programs: these are
represented by 'plugin' components.
Have you
On Jun 25, 2007, at 12:06 PM, skaller wrote:
On Mon, 2007-06-25 at 11:43 -0400, Peter Tanski wrote:
It would be much better to have a single build system. I would
gladly replace the whole thing ...
I am thinking of starting a new project (possibly as sourceforge)
to implement a new build
Certainly doable but it does present a conundrum: for the old GHC
(without builtin cl-support) the order for compilation seems to be:
compile/link command compile/link flags output source/object
files other flags
while for cl running link.exe or link.exe, it is better to put all the
files at
On Jun 25, 2007, at 12:55 PM, kyra wrote:
Certainly doable but it does present a conundrum: for the old GHC
(without builtin cl-support) the order for compilation seems to be:
compile/link command compile/link flags output source/
object files other flags
while for cl running link.exe or
On Mon, 2007-06-25 at 13:35 -0400, Peter Tanski wrote:
Maybe some gcc mimicing cl wrapper tailored specifically for GHC
building system could help? One more layer of indirection, but
could leave ghc driver relatively intact.
That's a good idea! Do you know if or how the mingw-gcc is
On Jun 25, 2007, at 3:34 PM, skaller wrote:
On Mon, 2007-06-25 at 13:35 -0400, Peter Tanski wrote:
Maybe some gcc mimicing cl wrapper tailored specifically for GHC
building system could help? One more layer of indirection, but
could leave ghc driver relatively intact.
That's a good idea!
Don't forget .. Mingw has to be installed too .. and in fact
that is much harder. I tried to install MSYS and gave up.
You're kidding right? There's Windows installer .exes for MinGW and
MSYS. You download it, run it, and click Next a few times.
Its far from that easy! Its loads of steps,
On Sun, Jun 24, 2007 at 12:45:33PM +0100, Claus Reinke wrote:
http://hackage.haskell.org/trac/ghc/wiki/Building/Windows#AWindowsbuildlogusingCygwin
that would help others in the future, and they can send
updates to the log when the details change. if you don't
remember all the details, just
On Sun, 2007-06-24 at 13:10 -0400, Matthew Danish wrote:
Unfold MinGW, MSYS, and MSYS Developer Tool Kit.
Hmm .. well I'm not sure if this is still correct, but Mingw,
being a Windows program, has 255 character limit on command line
.. which makes it useless for building anything complex.
Hi
Don't forget .. Mingw has to be installed too .. and in fact
that is much harder. I tried to install MSYS and gave up.
You're kidding right? There's Windows installer .exes for MinGW and
MSYS. You download it, run it, and click Next a few times.
Its far from that easy! Its loads of
Neil Mitchell wrote:
Hi
Don't forget .. Mingw has to be installed too .. and in fact
that is much harder. I tried to install MSYS and gave up.
You're kidding right? There's Windows installer .exes for MinGW and
MSYS. You download it, run it, and click Next a few times.
Its far from that
Peter Tanski wrote:
Maybe this depends on the type of convenience you want to offer
GHC-developers. With the autoconf system they are required (for
Windows) to download and install: Mingw, perl, python (for the
testsuite), flex, happy, alex and some others I can't remember right
now. Oh
On Fri, 2007-06-22 at 12:03 +0100, Simon Marlow wrote:
Ok, you clearly have looked at a lot more build systems than I have. So you
think there's a shift from autoconf-style figure out the configuration by
running tests to having a database of configuration settings for various
skaller wrote:
On Fri, 2007-06-22 at 12:03 +0100, Simon Marlow wrote:
Ok, you clearly have looked at a lot more build systems than I have. So you
think there's a shift from autoconf-style figure out the configuration by
running tests to having a database of configuration settings for various
On Jun 22, 2007, at 9:45 AM, Simon Marlow wrote:
skaller wrote:
On Fri, 2007-06-22 at 12:03 +0100, Simon Marlow wrote:
Ok, you clearly have looked at a lot more build systems than I
have. So you think there's a shift from autoconf-style figure
out the configuration by running tests to
On Fri, 2007-06-22 at 14:45 +0100, Simon Marlow wrote:
skaller wrote:
This misses the point. The 'suck it and see' idea fails totally for
cross-compilation. It's a special case.
The right way to do things is to separate the steps:
(a) make a configuration
(b) select a
On Jun 22, 2007, at 7:03 AM, Simon Marlow wrote:
In fact, to build a source distribution on Windows, there are only
3 dependencies: GHC, Mingw and (either MSYS or Cygwin).
To build from darcs, you also need: darcs, Happy, and Alex. To
build docs, you also need Haddock. To run the
Peter Tanski wrote:
A bit invasive (it involves modifying the make rules so they take an
object-suffix variable). Instead of the current suffix.mk:
$(odir_)%.$(way_)o : %.hc
it should be:
$(odir_)%.$(way_)$(obj_sfx) : %.hc
or some such. This may affect other builds, especially if for
On Jun 22, 2007, at 11:42 AM, Simon Marlow wrote:
Peter Tanski wrote:
A bit invasive (it involves modifying the make rules so they take
an object-suffix variable). Instead of the current suffix.mk:
$(odir_)%.$(way_)o : %.hc
it should be:
$(odir_)%.$(way_)$(obj_sfx) : %.hc
or some such.
On Thu, Jun 21, 2007 at 12:35:15AM +1000, skaller wrote:
Don't forget .. Mingw has to be installed too .. and in fact
that is much harder. I tried to install MSYS and gave up.
You're kidding right? There's Windows installer .exes for MinGW and
MSYS. You download it, run it, and click Next a
On 6/20/07, Isaac Dupree [EMAIL PROTECTED] wrote:
yes, binutils written in Haskell! Will never happen! :))
It's crossed my mind as well, once or twice -- maybe it's not such a bad idea.
Cheers,
Dinko
___
Glasgow-haskell-users mailing list
Peter Tanski wrote:
skaller wrote:
On Tue, 2007-06-19 at 12:23 +0100, Simon Marlow wrote:
Bulat Ziganshin wrote:
Hello glasgow-haskell-users,
are you plan to implement 64-bit windows GHC version?
The main thing standing in the way of this is the lack of a 64-bit
port of
mingw.
On Jun 21, 2007, at 4:16 AM, Simon Marlow wrote:
Peter Tanski wrote:
skaller wrote:
Why do you need mingw? What's wrong with MSVC++?
The largest problem is the build system: GHC uses autoconf with
custom makefiles.
So autoconf won't work with MSVC++, that is indeed a problem. But
this
Peter Tanski wrote:
The make system does work well and must be kept in order to port GHC to
a new posix platform--too many parallel projects (pun intended) work
with the current system. I have not kept a good count of monthly
configuration-based bugs but there are at least a few a month, for
On Thu, 2007-06-21 at 14:40 -0400, Peter Tanski wrote:
On Jun 21, 2007, at 11:48 AM, Simon Marlow wrote:
So you'd hard-wire a bunch of things based on the platform name?
That sounds like entirely the wrong approach to me.
FYI: there is a rather nice set of platform data in the
ACE
skaller wrote:
The key thing for the building portability is that the C and C++
compilers are represented by Python classes. There is a pre-programmed
class for gcc, and another for MSVC++.
I suggest (for GHC) a Haskell class with instances for the different
combinations of
compilers and
each sub-project...have a...Haskell program...building that sub-project
I was trying to build something like this recently but hit a roadblock.
Rather than execute the script in each directory, I wanted to import it as a
module instead. This way you can, for example, pass functions, like a
On Fri, 2007-06-22 at 02:06 +0100, Brian Hulley wrote:
skaller wrote:
(a) Pick a portable scripting language which is readily available
on all platforms. I chose Python. Perl would also do.
If I had time to look into improving the GHC build system I'd definitely
use Haskell as the
Brian Hulley wrote:
To port GHC to a completely new platform, you'd of course need a
Haskell
compiler or interpreter already. However to bootstrap the process
only a
slow interpreter would be needed so as long as a portable pre-built
bytecode version was available for download the only thing
skaller wrote:
On Tue, 2007-06-19 at 12:23 +0100, Simon Marlow wrote:
Bulat Ziganshin wrote:
Hello glasgow-haskell-users,
are you plan to implement 64-bit windows GHC version?
The main thing standing in the way of this is the lack of a 64-bit port of
mingw.
Why do you need mingw? What's
Bulat Ziganshin wrote:
Hello skaller,
Tuesday, June 19, 2007, 8:15:19 PM, you wrote:
are you plan to implement 64-bit windows GHC version?
Why do you need mingw? What's wrong with MSVC++?
really! Simon, how about unregisterised build?
Unregisterised would still need a C compiler capable
On Wed, 2007-06-20 at 08:49 +0100, Simon Marlow wrote:
I don't think we'll be able to drop the mingw route either, mainly because
while
the MS tools are free to download, they're not properly free, and we want
to
retain the ability to have a completely free distribution with no
skaller wrote:
On Wed, 2007-06-20 at 08:49 +0100, Simon Marlow wrote:
I don't think we'll be able to drop the mingw route either, mainly because while
the MS tools are free to download, they're not properly free, and we want to
retain the ability to have a completely free distribution with no
Hi
I'm not sure I understand this. MS tools are free to download
by anyone, but not redistributable. The binaries needed by
programs *built* by those tools are not only free to download,
they're free to redistribute, and they're less encumbered than
almost all so-called 'free software'
On Wed, 2007-06-20 at 14:42 +0100, Simon Marlow wrote:
The binaries needed by programs built by these tools..., you're referring
to
the C runtime DLLs? Why does that matter?
Note I said with no dependencies above. A Windows native port of GHC would
require you to go to MS and download
Neil Mitchell wrote:
Hi
I'm not sure I understand this. MS tools are free to download
by anyone, but not redistributable. The binaries needed by
programs *built* by those tools are not only free to download,
they're free to redistribute, and they're less encumbered than
almost all
skaller wrote:
GHC needs to target *professional windows programmers*.
They're going to have VS installed already. Haskell is far
too important a language (IMHO) not to have an entry in
the commercial programming arena.
Commercial programming is in a bad way! It NEEDS stuff like
Haskell
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Neil Mitchell wrote:
Typically MS tools are
well packaged and even if there is a click through license, it usually
involves checking a box and clicking next. I can't believe that anyone
is going to have any difficulty installing Visual Studio
-users@haskell.org; Bulat Ziganshin
Subject: Re: 64-bit windows version?
skaller wrote:
GHC needs to target *professional windows programmers*.
They're going to have VS installed already. Haskell is far
too important a language (IMHO) not to have an entry in
the commercial programming arena
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
skaller wrote:
(MS and gcc C++ are incompatible).
is this still true? GCC has been standardizing its C++ ABI for a while,
and I think there actually weren't any ABI changes noted between 4.1 and
4.2 for most platforms (I don't know if MS C++ is
skaller wrote:
On Tue, 2007-06-19 at 12:23 +0100, Simon Marlow wrote:
Bulat Ziganshin wrote:
Hello glasgow-haskell-users,
are you plan to implement 64-bit windows GHC version?
The main thing standing in the way of this is the lack of a 64-
bit port of
mingw.
Why do you need mingw?
| BTW: I don't really like Windows .. but I want to see Haskell
| succeed. Trying to do Haskell on Windows without MSVC++ toolchain
| is like trying to work on Linux without binutils... :)
|
| This is a fine point, and probably the biggest reason for doing a
| Windows native
| port. I'd like
Simon Marlow wrote:
GHC *developers* wouldn't be any better off either. You'd still
need either
Cygwin or MSYS for the build environment. There's no way I'm using
MS build
tools, ugh.
The way I have it set up (so far) is as simple as running configure
and make--all from the command
On Wed, 2007-06-20 at 11:39 -0400, Peter Tanski wrote:
The largest problem is the build system: GHC uses autoconf with
custom makefiles.
Well, that needs to be fixed. Autoconf and make are rubbish.
I have looked into porting the whole thing to a
Visual Studio project, using SCons
Bulat Ziganshin wrote:
Hello glasgow-haskell-users,
are you plan to implement 64-bit windows GHC version?
The main thing standing in the way of this is the lack of a 64-bit port of
mingw. The latest status update I could find is here:
On Tue, 2007-06-19 at 12:23 +0100, Simon Marlow wrote:
Bulat Ziganshin wrote:
Hello glasgow-haskell-users,
are you plan to implement 64-bit windows GHC version?
The main thing standing in the way of this is the lack of a 64-bit port of
mingw.
Why do you need mingw? What's wrong
51 matches
Mail list logo
