Malcolm Wallace (malcolm-nhc@cs.york.ac.uk)
Tue, 20 Feb 2001 16:36:58 +0000
> I have just compiled nhc98src-1.02 on Win2K under Cygwin, and it went > smoothly (which was not the case with 1.00, so congratulations on the > improvement). I'm glad to hear that my titanic struggles with an old and slow Win95 box have paid off in improving the Cygwin/nhc98 situation for others! > I have also tried to compile nhc98src-1.02 on FreeBSD RELEASE-4.2, but I > get these error messages running "make": > .... > Something to do with GNU make versus BSD make? Very probably. We use some GNU-specific features of make quite heavily throughout the build tree. I'd suggest installing it as 'gmake', like we do on our Solaris boxes to avoid conflicts with the existing make. > Above all, what Windows users would like to see is a version that could > be compiled by VC++ and then run like a native Windows program. I'm sure that a lot of people would appreciate such a facility. As I understand things, these are the main problems to solve: * nhc98 (and other compilers like ghc) are almost exclusively text-based. I don't know how things like "invocation by clicking an icon" and treatment of command-line arguments work in a Windows setting. If there are straightforward equivalences between the Unix way and the Windows way, great. * The runtime system currently uses many standard C libraries. I don't know how many of these are Unix-specific, and how many are truly standard to the extent of existing on Windows. However, it should be realatively easy to enumerate them against a check-list. * Shell scripts are used in various parts of the configuration and build system, as well as for the tool driver scripts (harch, nhc98, hmake, rtb, etc.). In turn these scripts use other common Unix commands like rm, mv, cp, basename, dirname. I would guess that all of the drivers would need to be recoded somehow (perhaps as Haskell scripts?) to use Windows filesystem calls directly. * I believe that Windows doesn't really have a proper 'make' tool, certainly not of the sophistication of GNU make. This may actually turn out to be the least difficult problem, because 'hmake' is probably capable of handling much more of the build process than at present. Here at York, none of us use Windows (in fact the 4-yr old 150Mhz Win95 box I already mentioned is the only one I could find, and even that runs Linux most of the time). For us to attempt a MS VC++ port would be too much effort for too little direct benefit to our projects. However, some of you Windows users must have the tools, the skills, and the motivation to give it a go. nhc98 is Open Source, so you don't even have to ask for our permission! We provide anonymous CVS access so you can keep in sync with our development tree. If you need some help in understanding the current build system, or driver scripts, or whatever, we are here on email to answer your questions. Should you succeed, we will happily incorporate your Windows port into the main development tree and future distributions of nhc98. Also please note that none of the porting issues I outlined above require any deep understanding of the compiler itself. They are all the kind of things that would be applicable to porting any piece of software from Unix to Windows. In that sense, the effort spent in learning how to solve them would be paid back by being able to re-use that knowledge in other situations. Any takers? Regards, Malcolm