On 11 Aug 1999 14:11:45 +0200, Lars Gullik Bj°nnes wrote:
>"Arnd Hanses" <[EMAIL PROTECTED]> writes:
>
>| Is this bug-bound? Everybody does it (at least in C), I'd say
>| configure
>
>Everybody does not use it...not even in C
Look into GNU-project sources...
(But as I'll already said, I'll insist on nothing and will rewrite it,
so you all like it. Don't worry, be happy!)
>
>| is severely broken in too many cases (not only with emx but on systems
>| like AIX, IRIX, CRAY etc., too). I'd better not trust this problematic
>| tool; even on Linux I had problems with tests depending in libc4/5.
>
>Where/when is configure broken?
Look into this mailing-list archive for examples. But many people are
so accustomed to edit config.h by hand and write their own Makefiles
from the templates, that they won't protest at all. At least for AIX
and CRAY, even for IRIX and SunOS this seems to be the case.
Unfortunately Imakefile isn't any better, because when vendor's patch
their systems (every second week they bugfix their bugfixes) normally
they 'forget' to adapt imake templates...
Shall I tell the story how SGI patched this uni's power challenge (gcc
doesn't work, you must use the native so called 'power compiler'), and
then people tried to remote-control experiments on CERN with standard
software compiled on this and nearly ruined CERN...
And for libc4/5 problems: Just try to compile arbitrary old software
from sunsite on your bleeding edge Linux-glibcxx box ...
>
>| >We can have the configure script (or the makefile) setup a link from
>| >os_specific.h to os2_defines.h, or os_default.h.
>|
>| I would like it more to put the actual C++ code into some os_suport.C
>| and leave the defines in os2_defines.h. I could use then in filetools.C
>|
>| #ifdef __EMX__
>| #include <os_suport.C>
>| #endif
>
>And then we are back to a multitude of #ifdefs for different
>systems...
Note the difference to clutter C++ function bodys with dozends of
#ifdef, or to have one conditional #include in the middle of other
#include statement.
Greets,
Arnd