Re: [Yhc] New Build System
On Sat, 3 Mar 2007 04:49:16 +0000 Neil Mitchell wrote:
... I was wondering if we'd have more success with something written purely in Haskell. <snip> * Everything is based on profiles, more on that once its done * Compile C files with GHC everywhere (will this go wrong?) <snip> It is not currently useable! The "Main configure" works and does the C configure tests and searches for GHC etc. "Main push" works fine. "Main yhc" will work if you have all the required packages pre-installed by Cabal - likely to only be me - but it does work.
The first thing that would certainly go wrong is compiling the Yhc RTS. It currently compiles only with MS CL--if I correctly understand another message you wrote: On Fri, 2 Mar 2007 22:54:38 +0000: Subject: Re: [Yhc] Problems installing YHC on Windows XP
We don't support the gcc from MingW, in fact we don't support GCC on Windows at all. We only support Visual Studio.
GHC only supports GCC. (Many apologies for flagging on the Windows- native port of GHC. (I have been desperate to finish the replacement library--adequately, i.e., better than or at least comparable to GMP-- running out of time (and money) and I admit I spend too much time experimenting with new algorithms. To my knowledge, an almost purely SIMD library has not been done before.)
There are only 3 things left to do which might go wrong/take some time:
1) Download dependancies automatically and install them with Cabal. Haskell's lack of a good wget/tar combo here may hurt us, but I'll see what code I can find lying around.
What about a direct interface to darcs? At least that way you could sponge off the darcs wrapper for curl.
2) Compile Yhi, which requires make-style knowledge about C. Scons had this built in much more, I'll need to roll my own.
Cabal with hooks might help, or at least pull things from Distribution.Simple.
Anyone have any thoughts?
As an alternative to using GHC to control the C-compiler, you might consider using VCBUILD from the command line for the current yhi .vcproj files. Towards that end, here is an unfinished module I started writing last January when we were talking about finding and obtaining the environment variables from vsvars32.bat. It probably should only use Distribution modules instead of System; it does not print the environment variables to a command file; and, it uses both Text.Regex and Text.ParserCombinators.Parsec but it might help: Cheers, Pete Tanski
Hi I'll answer Andrew's points later, as they are more detailed and require more thought.
The first thing that would certainly go wrong is compiling the Yhc RTS. It currently compiles only with MS CL--if I correctly understand another message you wrote:
On Fri, 2 Mar 2007 22:54:38 +0000: Subject: Re: [Yhc] Problems installing YHC on Windows XP
We don't support the gcc from MingW, in fact we don't support GCC on Windows at all. We only support Visual Studio.
That's only an issue of build system, we compile with Visual Studio because that is what works build system wise. The code should compile just fine with GHC.
1) Download dependancies automatically and install them with Cabal. Haskell's lack of a good wget/tar combo here may hurt us, but I'll see what code I can find lying around.
What about a direct interface to darcs? At least that way you could sponge off the darcs wrapper for curl.
I have actually implemented this, I just mirrored the repos to some web space, then execute darcs get --partial. Removes the need for untar and wget in one step, plus much simpler.
2) Compile Yhi, which requires make-style knowledge about C. Scons had this built in much more, I'll need to roll my own.
Cabal with hooks might help, or at least pull things from Distribution.Simple.
Talking to Malcom, I think its under 50 lines of code, and quite nice code at that.
Anyone have any thoughts?
As an alternative to using GHC to control the C-compiler, you might consider using VCBUILD from the command line for the current yhi .vcproj files. Towards that end, here is an unfinished module I started writing
Compiling C with GHC will work everywhere, VC will only work on Windows, gcc will only work (natively and normally) on Unix - hence the attraction of GHC. Adding back VS building afterwards would be a goal, so using your code at that point would be nice. The reason for favouring GHC is everyone has GHC installed, while I only have VS installed on one of my 3 development machines. Thanks Neil
On Mar 6, 2007, at 9:36 AM, Neil Mitchell wrote:
What about a direct interface to darcs? At least that way you could sponge off the darcs wrapper for curl.
I have actually implemented this, I just mirrored the repos to some web space, then execute darcs get --partial. Removes the need for untar and wget in one step, plus much simpler.
Right on!
2) Compile Yhi, which requires make-style knowledge about C. Scons had this built in much more, I'll need to roll my own.
Talking to Malcom, I think its under 50 lines of code, and quite nice code at that.
Nice.
Anyone have any thoughts?
As an alternative to using GHC to control the C-compiler, you might consider using VCBUILD from the command line for the current yhi .vcproj files. Towards that end, here is an unfinished module I started writing
Compiling C with GHC will work everywhere, VC will only work on Windows, gcc will only work (natively and normally) on Unix - hence the attraction of GHC. Adding back VS building afterwards would be a goal, so using your code at that point would be nice. The reason for favouring GHC is everyone has GHC installed, while I only have VS installed on one of my 3 development machines.
That was the direction GHC is moving in, as well: put all the platform-specific C-compiler knowledge into GHC. At least now the GHC Windows distribution comes with a minimal MinGW installation, as well. Cheers, Pete Tanski
participants (2)
-
Neil Mitchell -
Peter Tanski