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:
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
Gour wrote:
Have you seen Aap (http://www.a-a-p.org/) ?
I have A-A-P (or Aap) but I only did the basic hello-world build and
read the manual. It has in fact been updated as late as Febuary
2007. The Make-like syntax is elegant. Maybe someone else could
look at this and see if they want
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! Do
Hello Peter,
Monday, June 25, 2007, 9:35:31 PM, you 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!
there is possibility that such dr
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
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:
object files>
while for cl running link.exe or link.exe, it is better to put all
the files at the end of the comm
Certainly doable but it does present a conundrum: for the old GHC
(without builtin cl-support) the order for compilation seems to be:
files>
while for cl running link.exe or link.exe, it is better to put all the
files at the end of the command line:
It also adds one more layer of indi
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 sy
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
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
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 expli
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) : %.h
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.
Ocam
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,
> 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,
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 tha
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 s
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 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. Thi
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 some
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 testsuit
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 h
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
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 variou
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
> pla
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 yea
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
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 s
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
logg
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 pla
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 p
On Jun 21, 2007, at 11:48 AM, Simon Marlow wrote:
Peter Tanski wrote:
If I could change one feature of the current system ... for known
systems use autoconf only to determine what the $(build) system is
and to ensure those programs are available, then jump into make
which would call pre-set
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 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:
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
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
Gla
Hello skaller,
Thursday, June 21, 2007, 7:06:09 AM, you wrote:
>> generally speaking, people want to use 64-bit code in order to work
>> with much larger data space, overall speed may be better than using
>> 32-bit version with 2gb limit
> With x86_64, 64 bit programs are usually faster than 32 b
On Wed, 2007-06-20 at 22:59 +0400, Bulat Ziganshin wrote:
> generally speaking, people want to use 64-bit code in order to work
> with much larger data space, overall speed may be better than using
> 32-bit version with 2gb limit
With x86_64, 64 bit programs are usually faster than 32 bit ones
ev
On Wed, 2007-06-20 at 11:40 -0400, Isaac Dupree wrote:
> -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
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 (
Hello Simon,
Wednesday, June 20, 2007, 11:51:34 AM, you wrote:
>> really! Simon, how about unregisterised build?
> Unregisterised would still need a C compiler capable of generating 64-bit
> code.
> Are you talking about using the MS compiler for that? Certainly possible,
> but
> I'm not sur
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 line
| > 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
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?
-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 comp
-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
-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 e
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 availab
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 so-
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
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'
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 n
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
>
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
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 w
On Wed, 2007-06-20 at 07:34 +0400, 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?
>
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?
skaller, is *free* 64-bit msvc (or any other windows c++ compiler) available
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 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:
http://sourceforge.net/mailarchive/message.php?msg_id=4
Hello glasgow-haskell-users,
are you plan to implement 64-bit windows GHC version?
--
Best regards,
Bulat mailto:[EMAIL PROTECTED]
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.or
61 matches
Mail list logo
