[Monetdb-developers] [Monetdb-checkins] buildtools/conf MonetDB.m4, MonetDB_1-20, 184.108.40.206, 220.127.116.11
Stefan.Manegold at cwi.nl
Wed Nov 21 17:38:46 CET 2007
On Wed, Nov 21, 2007 at 05:18:25PM +0100, Fabian Groffen wrote:
> On 21-11-2007 15:07:04 +0000, Stefan Manegold wrote:
> > +case "$host-$GCC-$CC-$enableval" in
> > +ia64*-*-*-32)
> > + AC_MSG_ERROR([we do not support 32 bits on $host]);;
> So HPUX's 32-bits support on ia64 is not supported :(
AFAIK, we never supported HPUX, basically, because we never had access to
any HPUX machine. So far, I have not received either any request for
supporting HPUX, or any complaint about us not doing so.
Of course, after years without change, we could consider making this test
more specific, refering to Linux, only ...
> > +i?86*-*-*-64)
> > + AC_MSG_ERROR([$host does not support 64 bits]);;
> So Darwin's multilib compiler (i386-apple-darwin) is assumed not to
> handle 64-bits code here :(
64-bit (only) code on/for a 32-bit architecture?
I don't think, we do support "multilib" compilation at all --- at least I
actually don't know how that works, but of course, I'm always open and
curious to learn more...
> > +*--icc*-32|*--icc*-64)
> > + AC_MSG_ERROR([icc does not support a command line option to switch between 32- & 64-bit compilation; use CC & PATH (instead of --enable-bits=$enableval) to point to the $enableval-bit version of icc]);;
> > +*-*-*-32|*-*-*-64)
> > ;;
> > -*) AC_MSG_ERROR(--enable-bits argument must be either 32 or 64);;
> > +*)
> > + AC_MSG_ERROR(--enable-bits argument must be either 32 or 64);;
> Clever one ;)
The same reason that triggered this check also triggered the above ones:
allow only what has been tested and confirmed to work. Prevent any unknown
situations. Otherwise, (some) users complain about "I (accidently?) used
this-and-that flag, compilation did not complain, but then nothing worked".
Of course, the strict approach raises questions as the ones given above ---
I would be glad to hear the "ultimate" solution that suits "everybody",
"innocent users" that what a "completely fool-proof" system, and
"dare-devils" that want to discover new worlds.
For now, the best "compromise" I could find is to tend towards the
strictness as default, assuming that the dare-devils are willing to get
their fingers dirty and know how to disable the strict checks where-/whenever
| Dr. Stefan Manegold | mailto:Stefan.Manegold at cwi.nl |
| CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ |
| 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 |
| The Netherlands | Fax : +31 (20) 592-4312 |
More information about the developers-list