Re: Yasm r1713 fixed; building and Windows-native
Peter Tanski <[email protected]>
| Newsgroups | gmane.comp.lang.haskell.cvs.all |
|---|---|
| Message-ID | <BC8C99F2-F415-4B4F-BBE6-67BD60CFF746__1953.33623928509$1166592625$gmane$org@cox.net> |
On Dec 19, 2006, at 7:50 PM, Neil Mitchell wrote: >> Have you looked into Bakefile or Interscript? CMake looks more >> powerful than Bakefile, which ends up using nmake on Windows, while >> Interscript is really a literate programming language with the >> ability to execute scripts. Interscript works very well for Felix >> but it is a bizarre system to work with. > > No, haven't really looked at others than that. The original Yhc reason > for going to Scons was that KDE 4 is going to use it for all > platforms, including Windows. Since then, then dropped Scons and moved > to CMake - I am just playing follow the leader :) I am doing essentially the same thing trying to get a Windows build together--trying to find a build system that: (1) makes changes easy; (2) encapsulates dependency searches for various operating systems and compiler settings for various compilers (gcc, CL); and, (3) manages different build types, including tests. So far, (2) is the main concern for Windows. My real worry is Windows Vista: the most recent reports I have seen show that mingw32 requires a special runtime dll and Administrator privileges to run while cygwin is buggy. The immediate problem GHC has is the CL compiler--and, probably, default front-end for the linker, depending on the link options required. Unless someone wants to redo the current Autotools build system to use the CL compiler and promptly discard it for a Windows-native build, the best thing to do is convert the build system to one that will use the CL compiler automatically. > I think Yhc will stick with Scons for a while yet, but if you do find > what the "one true answer" is, we'd love to hear it! If I am the one who ends up rewriting the build system for GHC, chances are I will have learned enough to write Yhc's for you :) >> It might be possible to >> adapt or extend Cabal, even... > > As it currently stands, that sounds like a very painful way to uncover > new cabal bugs :) The way Cabal works, in the absence of Make everything would have to be done with hooks in Distribution.Simple and in any case it won't work outside of MSYS or Cygwin because it relies on configure shell scripts :( Dash it all, this is Haskell we are dealing with here! Although making a build system involves creating a small scripting language, interfacing to different system types (for search, file names, compilers, etc.) and managing directories, recompilation and testing it can't be that difficult to do it in Haskell; GHC's --make does a lot of the work already and (from the Yhc page) Yhc will support --depend enough fairly soon. A really great system would be truly dynamic (create functions on the fly) for certain operations and a truly excellent system may even be interactive, so users may correct errors and continue compiling--Lispy stuff. Just an idea. Cheers, Pete