David,
On 19 May 2014, at 15:42, David Matthews <David.Matthews at prolingua.co.uk> wrote:
Rob,
On 18/05/2014 17:36, Rob Arthan wrote:
I am trying to understand my options for using Poly/ML on MinGW for building windows applications coded in Standard ML.
There is a bug reported in http://sourceforge.net/p/mingw/bugs/2043/ that you have to work around to build Poly/ML with the current MinGW. The work-around is to run configure with CXXFLAGS="-D_GLIBCXX_HAVE_FENV_H=1? in the environment. (I suspect I should also throw -O3 in there too, as I think that setting CXXFLAGS replaces its initial setting of -O3 inside the makefiles. Is that right?)
I suspect it is. I wasn't aware of the need for _GLIBCXX_HAVE_FENV_H=1 but it's quite a while since I last used Mingw. It isn't clear from the link whether this is something the Poly/ML configure should do or not.
I agree that it wasn?t very clear whether this was thought to be a bug in the MinGW header files or not.
Having got Poly/ML to compile, I found that polyc gives errors like the following when asked to compile a source file:
gcc.exe: error: C:/DOCUME~1/rda/LOCALS~1/Temp/polyobj.2724.obj: No such file or directory
Again, I haven't tried this with Mingw. I'll take a look.
Thanks.
If I create an object file from the Poly/ML GUI using PolyML.export, polyc will link it. If I understand what is going on correctly, the resulting program is a Windows application that brings up the Poly/ML GUI to provide the standard input, output and error channels, unless it is run with standard input and output connected to pipes, in which case it works like a pipe. I think I may end up having to package the Standard ML parts of my application as a server, with the GUI provided by clients implemented in some other language. Are there any other options?
I think there are three possible options for building Poly/ML on Windows: Mingw, Visual C or Cygwin. If you use Mingw or Visual C you are building the native Windows version. This version does put up the GUI, as you say, if the standard input and output are missing. This is actually done by the RTS before the ML code is entered so applies equally to functions exported with PolyML.export as to the usual Poly/ML read-eval-print loop. Actually, it occurs to me that it is now possible to write the GUI in ML and include it as part of the top-level root function in Windows. This would allow a user-exported function to completely by-pass it. I think a GUI is necessary for Windows applications since that is what Windows users would expect.
I would actually have expected the ?GUI? to be a command prompt window. I.e., I would have expected poly to be a console application. This is how python comes, for example. Something that behaves like a console application is what cc on MinGW seems to give you if you don?t give it any of the Windows-specific command line options when you compile a standard C program.
Using Cygwin might be a possibility if you are thinking of providing a separate GUI. The package that Makarius has provided for running Isabelle on Windows uses Poly/ML under Cygwin but all the user interaction is through jEdit. There might be issues, though, if you wanted the ML code to access the Windows filing system because Cygwin imposes its own view of the filing system.
Cygwin does work for me, but unfortunately, having to install it is a stopper for some of my potential users. I tried compiling under MinGW with __CYGWIN__ set, but it doesn?t work. Would it be difficult to separate the choice between polystub.c being a standard C application and a Windows application from the __CYGWIN__ flag?
Regards,
Rob.