Gabriel Dos Reis wrote:
On Fri, Sep 4, 2009 at 3:49 AM, David
Matthews<[email protected]> wrote:
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.
OK,thanks! Is it reasonable to expect that restriction to be lifted
in a recent future?
It should work in the next release. I've added support for an option to
indicate where the source files are to be found but at the moment the
pre-built compilers in the imports directory don't understand this.
Looking at sighandler.cpp:142, I'm under the impression that the line
#if (!defined(WINDOWS_H) && defined(HAVE_LIBPTHREAD) &&
defined(HAVE_PTHREAD_H) && defined(HAVE_SEMAPHORE_H))
should just be
#ifdef USE_PTHREAD_SIGNALS
because that macro is already defined at line 86. Is that correct?
Yes, I've tidied this up.
After I locally made that change, the build progressed a bit further.
I could not see anything wrong at line 527. I had a look at the header
<semaphore.h> under /mingw/mingw32/include and found that indeed
sema_open is declared there to return an int. The macro SEM_FAILED
is not defined. so my current recommendation is to avoid
<semaphore.h> on MinGW. (test for the C preprocessor __MINGW__)
Actually, this shouldn't be used if the pthread library isn't used.
I've changed the ifdefs so that it doesn't include this. Generally, I
try to avoid having ifdefs that check for specific operating systems.
It's better to check for the presence of specific features.
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.
Well, my worry is that an unconditional test that looks for an OS-specific
header may report an unreliable result. For example, I would
suggest NOT testing for <semaphore.h> when on MinGW:
I guess this a matter of taste. I prefer to have configure report what
is present or absent and then to make the choices about what to use in
the code itself. There's sometimes a series of options depending on
exactly what is available. In this case semaphore.h is present so
configure should report that. It may be that it can't be used in this
particular place but it could be used elsewhere.
Incidentally, I've just installed MinGW/MSys and semaphore.h isn't
there. I have fixed a few other things and built poly successfully so
if you update from SVN it should work.
Regards,
David
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
