Compiling WinHugs (on Windows) in 2006, in 2020

[Anthony Clayden]

[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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/hugs-bugs/attachments/20200508/03b7e7c7/attachment.html>