Compiling WinHugs (on Windows) in 2006, in 2020
Anthony Clayden <[email protected]> Fri, 8 May 2020 15:52:46 +1200
| Newsgroups | gmane.comp.lang.haskell.hugs.bugs |
|---|---|
| Message-ID | <CAM7nRYS19Xg1hK6KjGGx93YZ+Qz5iFJZ3a+-hvs0TVnjwxfogQ@mail.gmail.com> |
--===============4324038880190401890== Content-Type: multipart/alternative; boundary="000000000000b4f6c905a51aee7e" --000000000000b4f6c905a51aee7e Content-Type: text/plain; charset="UTF-8" [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 --000000000000b4f6c905a51aee7e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">[Yes I don't expect anyone will read this. I'm lea= ving it for the record.]<div><br></div><div>No surprise that compiling WinH= ugs wasn't plain sailing. What's more remarkable is that it did eve= ntually compile (with Microsoft Visual C/C++ under Visual Studio); and that= most of the difficulties in getting a working system were with the Unix si= de, compiling Libraries.</div><div><br></div><div>(If you want a working sy= stem quickly and aren't interested in changing the libraries/packages, = I suggest stealing the packages from a WinHugs object distro.)</div><div><b= r></div><div>Most of the Unix difficulties/needed changes have been worked = through by Franklin Chen, to whom much thanks. See his repo=C2=A0<a href=3D= "https://github.com/FranklinChen/hugs98-plus-Sep2006">https://github.com/Fr= anklinChen/hugs98-plus-Sep2006</a></div><div><br></div><div>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. T= hat's why I'm filing as a bug.</div><div><br></div><div>The instruc= tions in /docs/building/win32.txt for '<span style=3D"color:rgb(36,41,4= 6);font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,mo= nospace;font-size:12px;white-space:pre">Driving Microsoft Visual C++ from t= he Command Line (out-of-date)</span>' are not just out of date but down= right wrong. Perhaps this was still possible immediately after moving to MS= VC, but by Sep 2006 the Makefile was unusable: it refers to all sorts of co= mponents that no longer exist/at a guess disappeared after early 2005.</div= ><div><br></div><div>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 b= e moved aside. Indeed if you're modifying (Win)Hugs shared artefacts (l= ike parser.y) and recompiling both WinHugs and command-line hugs/runhugs/ff= ihugs; moving those .h files about is a pain.</div><div><br></div><div>The = `make` does do one useful thing: compile echodate.c and run it to create ec= hodate.h. That's #include'd in /src/version.c to version-stamp your= .exe's -- except on Windows the compile demands the=C2=A0#include then= ignores it.=C2=A0 I'll come back to that.</div><div><br></div><div>For= Windows, the instructions i Win32.txt say "</div><table class=3D"gmai= l-highlight gmail-tab-size gmail-js-file-line-container" style=3D"color:rgb= (36,41,46);font-size:14px"><tbody style=3D"box-sizing:border-box"><tr style= =3D"box-sizing:border-box"><td id=3D"gmail-LC100" class=3D"gmail-blob-code = gmail-blob-code-inner gmail-js-file-line" style=3D"box-sizing:border-box;pa= dding-right:10px;padding-left:10px;line-height:20px;vertical-align:top;over= flow:visible;font-size:12px;white-space:pre"><font face=3D"garamond, times = new roman, serif">Open the project files located in msc (for the plain inte= rpreter) </font></td></tr><tr style=3D"box-sizing:border-box"><td id=3D"gma= il-L101" class=3D"gmail-blob-num gmail-js-line-number" style=3D"box-sizing:= border-box;padding-right:10px;padding-left:10px;width:50px;min-width:50px;f= ont-size:12px;line-height:20px;color:rgba(27,31,35,0.3);text-align:right;wh= ite-space:nowrap;vertical-align:top"></td><td id=3D"gmail-LC101" class=3D"g= mail-blob-code gmail-blob-code-inner gmail-js-file-line" style=3D"box-sizin= g:border-box;padding-right:10px;padding-left:10px;line-height:20px;vertical= -align:top;overflow:visible;font-size:12px;white-space:pre"><font face=3D"g= aramond, times new roman, serif">and winhugs (for the GUI interface). </fon= t></td></tr></tbody></table><div>". That'll lead you wrong.</div><= div><br></div><div>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 upgr= ading the whole thing to current level. (Comes up to VS 2019 ok -- eventual= ly.) Whereas opening the 'project file' -- i.e. the .vcproj will al= so tell you you have an out-of-date project structure; then take a much sho= rter time allegedly upgrading but actually stamping all over the place leav= ing an unusable mess. (Restore the whole directory from repo and start agai= n; there's no hope of repairing it.)</div><div><br></div><div>Attemptin= g to build from VS will fail to find echodate.h (see above). Don't stuf= f 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 20= 20 rather than Sep 2006.</div><div><br></div><div>There's a few other b= its 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 s= tandard.</div><div><br></div><div>There are a lot -- I mean a really big lo= t -- of Microsoft warnings about deprecated functions. I started to investi= gate these, but got overwhelmed; and eventually concluded this is Microsoft= =C2=A0being paranoid about functions that are standard C but Ms don't l= ike -- because they never really believed in a public-standards-based langu= age 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 fa= ll in a heap wanting non-existent functions.</div><div><br></div><div>And .= .. I now have WinHugs built from source by Visual Studio. Indeed I'm mo= difying `parser.y` and recompiling (needs a Unix bison step) happily.</div>= <div><br></div><div>Then all credit to the original Win/Hugs development te= am in producing robust software. I have to say a 14-year-old system is stil= l more friendly and Windowsy=C2=A0to use than anything from that Glasgow lo= t.</div><div><br></div><div>AntC</div></div> --000000000000b4f6c905a51aee7e-- --===============4324038880190401890== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSHVncy1CdWdz IG1haWxpbmcgbGlzdApIdWdzLUJ1Z3NAaGFza2VsbC5vcmcKaHR0cDovL21haWwuaGFza2VsbC5v cmcvY2dpLWJpbi9tYWlsbWFuL2xpc3RpbmZvL2h1Z3MtYnVncw== --===============4324038880190401890==--