On Thu, May 17, 2001 at 02:11:07PM +0200, Ralf Corsepius wrote:
> Alexander Mai wrote:
> >
> > I just need to cry out somewhere ...
Note this ...
> > 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 ...
> >
> > - 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
> >
> > - 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!
> Oooh, hold it! Do you really think your wording is appropriate?
Depends.
As my other mail showed and this shows I'm really of this opinion,
though it's not polite to use this wording in public ...
> As a long term auto* tool user, you should know how to force using
> particular tools (E.g. Do not use AC_PROG_YACC, but write your own
> LT_PROG_YACC).
> Wrt. yacc: Many yaccs are broken and bison -y is supposed to supply
> a compatible replacement.
see other mail.
Notice the "supposed".
Also this holds for various other tools (I think awk, make, sed are candidates).
But it doesn't help if you are misleading people by macro names.
> > 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??
> They do. However, what do you expect? People like you should report
> problems to the appropriate lists otherwise nobody will be able to
> fix them.
Might help or not.
I never got any official answer to my problems with autoconf/CSV&libtool 1.4
I tried to look in the docs and haven't found the answer.
(ok, that's not WRT bison ...)
> So, instead of ranting the way you are doing here, you'd better file
> bug reports or report your problems to the appropriate lists
> ([EMAIL PROTECTED]).
see above
> > - libtool 1.4 requires autoconf/CVS on alpha-linux.
> > This in turn is not compatible to the earlier release and so
> > installing it is no pure fun
> Consequently you should fix your stuff to get it working w/
> autoconf/CVS, or refrain from using libtool-1.4 and/or document
> alpha-linux as not supported (If it didn't work with older libtool
> versions this is no loss, if it did, continue using the older
> libtool-version).
I shall now look in my ~/compile tree, check for broken configure's
and fix them???
It was the idea of autoconf that people don't have to edit things,
just run configure. And for most subdirectories in this compile/
I'm not the author, so I'd prefer if they just continue to work.
> > - left-over of some major bug in automake still in the patched 1.4-p1 release.
> > (we need to define some vars both conditionally and unconditionally)
> Why do you think automake is being basically reworked for more than
> a 1.5 years now. 1.4-p1 is nothing but a bug-fix-release to
> automake-1.4 to get libtool-1.4 working with automake at all.
That's the point of maintaining 3 tools for basically the very same
task. Or why is dealing e.g. with some fPIC flags for shared lib building
really different from teh compiler flags for ANSI compatibility??
One is done by libtool and another by automake _and_ autoconf.
(though it seems the upcoming version might try to get things
better sorted?!)
> > Probably I should x-post to the bug-aut*@ lists, but I guess it won't
> > help much.
> You can't be serious ...
>
> Ralf
I'm seriously upset with this stuff, indeed.
As an user which doesn't have a home-PC with some
linux but has a particular strange setup
(e.g. being non-root on alpha machines; major stuff is not
in /usr/* but in ~/; etc.) I have to fight with configuration
all the time. And I really miss some support from those tools
which were supposed to do so ...
I'm also upset with people which for whatever reasons may have
worked longer on/with un*x than my couple of years and therefore
somehow conside to always do "The right thing (TM)" but silently ignore
that things actually _are_ broken. Or why do people still put efforts
in supporting KR compilers instead of trying to tell my
ANSI capable DU-cc on how to do it? In my limited experience
you can't build some recent arbitrary application on a system which has
only pre-ANSI C since for anything but hello_world.c you need
other tools/libs which demand ANSI C meanwhile.
(I can hardly resist to put in some statements concerning support
of OS/2 in those tools; we're already off-topic but this may
become too far away ;-)
--
Alexander Mai
[EMAIL PROTECTED]
