On Thu, May 17, 2001 at 12:35:37PM +0100, David Starks-Browning wrote:
> On Thursday 17 May 01, Alexander Mai writes:
> > I just need to cry out somewhere ...
> >
> > Again I am trying to get lesstif build on DU 4.0 w/o any explicit settings
> > in the environment. It seems those beloved auto* tools are just to
> > stupid ...
>
> Apologies for remaining rather ignorant of auto* tools, but...
>
> Are you complaining about what *you* have to do in order to tar a
> source distribution, or what *we* have to do in order to
> "configure + make + make install"?
The latter. On how to get things build.
> I just ran
>
> ./configure --prefix=/sw/common --exec_prefix=/sw/arch
> make
> make install
>
> and it worked fine on DU 4.0. At all times, my environment contains
>
> CPPFLAGS=-I/sw/common/include
> LDFLAGS=-L/sw/arch/lib -Wl,-rpath,/sw/arch/lib
>
> because it's necessary for us. (On all platforms, and with all
> packages we install.)
>
> > - AM_PROG_CC_STDC
> > doesn't check nearly for ANSI conformance. All - really all it does
> > it checking support for prototypes or something like this.
> > Result: so far it didn't work out w/o explicit setting of CFLAGS
>
> I have gcc in my path, and I had no difficulty. Are you trying to
> accomodate Digital /usr/bin/cc users? Aren't vendor compilers always
> going to be more trouble then they're worth, unless the user is
> willing to specify the right options manually?
You are 'cheating' and are using gcc ...
While gcc _meanhwile_ seems to be an option on DU, it wasn't for most
time on its life on the alpha processor.
(still gcc 2.95.2 had e.g. a lot of broken C++ stuff which worked
fine with gcc on e.g. i86-linux)
As I confess Digital's cc is also quite stupid and does its best
to avoid cooperation with the auto* tools, but that's their job
to deal with stupid compilers.
> > - AC_PROG_YACC
> > which idiot creates such a macro which unlike it's name uses
> > bison by default if found? Default should be to use yacc!
> > The GNU one also has brain-dead handling of __STDC__ and const
> > and all this. Why don't those people never test such things
> > on more than their development machine??
>
> IIRC, some systems ship with a "broken" yacc (sorry I forget which).
> I have /usr/bin/yacc *and* GNU bison 1.28. 'configure' picked up
> bison and everything worked for me.
Yes.
But
a) the name shouldn't contain "YACC" if it doesn't pick up this.
Use AC_PROG_WHATEVER or AC_PROG_YACCLIKE
b) they could _test_ whether yacc is broken
and
c) bison 1.28 does horrible things.
The example we have in clients/*/uil/yacc.y is not nice
but a tool which redefines "const" in the middle of some
emitted code is brain-dead
(BTW, I seem to like such strong vocabularies which is not really true.
However if I run across such programming sins, I can't resist. And I can't
resist if tools supposed to aid in configuration do the opposite)
> > - libtool 1.4 requires autoconf/CVS on alpha-linux.
>
> (I thought we were talking about Digital UNIX...)
>
> Of course I'll feel pretty stupid if I'm missing something here, but I
> just finished building 0.92.29 on Digital UNIX 4.0D, so I thought I
> would chime in.
Sorry, I dared to add another example for the flaws in those tools.
If you now claim correctly that let's say 90% of all users can
run configure&&make fine on their system ... so what?
e.g. NEdit ships with a dozen of Makefiles for different platforms.
It probably has the same success rate, though developers don't
spend as much time on the code as on configure.in/Makefile.am ... :-(
--
Alexander Mai
[EMAIL PROTECTED]
