Compiling WinHugs (on Windows) in 2006, in 2020

Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Compiling WinHugs (on Windows) in 2006, in 2020

AntC
[Yes I don't expect anyone will read this. I'm leaving it for the record.]

No surprise that compiling WinHugs wasn't plain sailing. What's more remarkable is that it did eventually compile (with Microsoft Visual C/C++ under Visual Studio); and that most of the difficulties in getting a working system were with the Unix side, compiling Libraries.

(If you want a working system quickly and aren't interested in changing the libraries/packages, I suggest stealing the packages from a WinHugs object distro.)

Most of the Unix difficulties/needed changes have been worked through by Franklin Chen, to whom much thanks. See his repo https://github.com/FranklinChen/hugs98-plus-Sep2006

He compiled on Mac, so this is to record difficulties specific to Windows/WinHugs. Firstly, though, there's stuff that must have been just plain wrong in 2006. That's why I'm filing as a bug.

The instructions in /docs/building/win32.txt for 'Driving Microsoft Visual C++ from the Command Line (out-of-date)' are not just out of date but downright wrong. Perhaps this was still possible immediately after moving to MSVC, but by Sep 2006 the Makefile was unusable: it refers to all sorts of components that no longer exist/at a guess disappeared after early 2005.

However there's one bit that's needed but not mentioned in the MSVC instructions: the three .h files in /src/winhugs and (different files same names) in /src/msc: must be copied in to the parent /src/ directory, and the ones in /src/ (created by ./configure) must first be moved aside. Indeed if you're modifying (Win)Hugs shared artefacts (like parser.y) and recompiling both WinHugs and command-line hugs/runhugs/ffihugs; moving those .h files about is a pain.

The `make` does do one useful thing: compile echodate.c and run it to create echodate.h. That's #include'd in /src/version.c to version-stamp your .exe's -- except on Windows the compile demands the #include then ignores it.  I'll come back to that.

For Windows, the instructions i Win32.txt say "
Open the project files located in msc (for the plain interpreter)
and winhugs (for the GUI interface).
". That'll lead you wrong.

Open the .sln file: Visual Studio will then tell you you have an out-of-date project structure; and will then take a long time upgrading the whole thing to current level. (Comes up to VS 2019 ok -- eventually.) Whereas opening the 'project file' -- i.e. the .vcproj will also tell you you have an out-of-date project structure; then take a much shorter time allegedly upgrading but actually stamping all over the place leaving an unusable mess. (Restore the whole directory from repo and start again; there's no hope of repairing it.)

Attempting to build from VS will fail to find echodate.h (see above). Don't stuff about trying to build that, just comment out the #include in /src/version.c -- in fact while you're at it, edit that to take a version of May 2020 rather than Sep 2006.

There's a few other bits of .c code that won't compile; including in filecode.cpp an out-of-scope use of a for-loop variable that's not compliant with the 1999 C standard.

There are a lot -- I mean a really big lot -- of Microsoft warnings about deprecated functions. I started to investigate these, but got overwhelmed; and eventually concluded this is Microsoft being paranoid about functions that are standard C but Ms don't like -- because they never really believed in a public-standards-based language anyway. You can put #pragmas if you want to suppress the warnings; but don't change the code to comply, because then the build on Unix will fall in a heap wanting non-existent functions.

And ... I now have WinHugs built from source by Visual Studio. Indeed I'm modifying `parser.y` and recompiling (needs a Unix bison step) happily.

Then all credit to the original Win/Hugs development team in producing robust software. I have to say a 14-year-old system is still more friendly and Windowsy to use than anything from that Glasgow lot.

AntC

_______________________________________________
Hugs-Bugs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/hugs-bugs