This still feels like a brittle solution to me.
But an ABI is one of the most solid conventions on any platform, so I really can't see a problem here.
I believe that testing what your actual machine does and does not support is the right approach when not cross-compiling.
Granted (almost :-).
I appreciate that some people may disagree here but if you do agree, then surely the same applies when cross-compiling and the only issue is how to implement such an approach?
So, I'll ask again:
Can we split our autoconf scripts into two parts: one to be run on the host machine and one to be run on the test machine?
:-P * * * Seriously: Should the configure script run tests via rsh/ssh? And what if the target platform can't be reached remotely? I've never seen such an autoconf trick before...
My suggestion is:
* If the test can be done via compilation (for the target platform!) alone, just do it that way (e.g. compile-time constants like EAGAIN etc.)
* If the test can't be done via compilation alone, try the following in order:
* If the test is very closely tied to the target host/platform (e.g.
ABI-related stuff like underscores on external names) and it is a known
host/target platform, use a case/switch on the host/target platform name. * If we are cross-compiling, we are out of luck: Abort! (with a suggestion,
if possible, like "you probably don't need an underscore because the
host/target platform looks like ELF").* Use a runtime test.
Cheers, S.
_______________________________________________ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
