David, On 19 May 2014, at 15:42, David Matthews <david.matth...@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.
_______________________________________________ polyml mailing list polyml@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
