Hi Gabriel,
Gabriel Dos Reis wrote:
I tried to build Poly/ML on Windows using the MSYS/MinGW toolchains, but was unsuccessful The build failed with:
This is an out-of-source build, meaning that I keep the build directory separate from the vanilla Poly/ML source tree. I had a quick look for winconfig.h and was under the impression that it was supposed to replace config.h (which is generated anyway at configure time). For some reason, it is not being seen by the preprocessor. Why keep winconfig.h when config.h (that truly reflects the host/build machine characteristics) is generated at configure time?
Doing an out-of-source build won't currently work. You may be able to build the library but compiling the basis library into Poly/ML assumes that it is running within the directory that contains the sources.
The reason for winconfig.h is that config.h is only built if you run configure. When building using Visual C++ there's no configure step so there needs to be a header file that defines the default set-up on Windows. In a few cases the code currently checks first for HAVE_CONFIG_H and uses configure.h if that is set and and falls back to winconfig.h if it isn't. I think that should be done everywhere.
I also noticed that pthread is being check for even on Windows. I believe that is not good. On Windows, one should just check for Windows thread support. The reason is that configure may report that pthread.h exists without the full semantics support needed by Poly/ML (which is the case on my machine, Windows XP SP3). A second point is that in such circumstances, checking for HAVE_PTHREAD_H, then for WIN32 is not good. The test should be reversed. One should first check for WIN32, then HAVE_PTHREAD_H.
That's a good point.
Another observation: __darwin_mcontext32 should be checked only on darwin platforms.
There are various header files that are operating-system specific. It's easier and probably more reliable to search for the files in all cases rather than only check on certain platforms. Unless it breaks something I'd prefer to leave it as it is.
Regards, David