AW: Re[6]: C/C++ projects don't work for suse 7.2, suse7.3 and upcoming kdevelop 2.0.2

Roland Krause rokrau at yahoo.com
Wed Nov 14 18:50:31 UTC 2001


I know, I should not say this but here it goes:

Autoconf has become much worse of a problem then the one it tried to
solve.

This doesn't help you in any way, but if some person would like to
become a real hero in the free software community, that's the project
to get on.

Roland

--- Markus Kuehni <markus.kuehni at trilab.ch> wrote:
> Hi
> 
> Otto wrote:
> > AC_CHECK_HEADER( [headerfile.h], [AC_DEFINE([HAVE_HEADERFILE_H])],
> > [AC_MSG_ERROR([Get yourself that headefile])] ) or
> > AC_CHECK_HEADERS( header1.h header2.h header3.h etc )
> >
> > AC_CHECK_LIB( libname, function to check for, action if found,
> action if
> > not found )
> >
> > AC_CHECK_LIB( [m], [cos], [AC_DEFINE( [HAVE_COS] )],
> [AC_MSG_ERROR([You
> > dont have the math lib])])
> 
> After having read multiple tutorials, most of the book "GNU Autoconf,
> Automake and Libtool" (G.V.Vaughan et al., New Riders), having spent
> hours
> browsing man and info pages I was able to "distill" as much.
> 
> IMO the most "frustrating" aspect of auto* tools usage is the
> complete lack
> of a clear layering. There are no real "levels of abstraction".
> Instead
> everything is somehow "morphed" into the "lower-but-not-quite" layer.
> Autoconf does not hide configure, it adds to it. Automake does mostly
> hide
> Makefile.in (AFAIK) but it does not hide Autoconf - it adds to it.
> Libtool
> is the complete confusion.
> 
> This "adding but not hiding" is very confusing (and error-prone) as
> you
> don't know which API of the "lower" level is actually to be replaced
> by the
> "higher" level.
> 
> Each text I read (so far) is beginning with Adam and Eve,
> introducting
> Makefiles, configure then adding Autoconf (and in the course
> confusing you
> with m4), then adding Automake and telling you what you learned in
> the
> preceding chapter is no longer valid, use AM_* instead, oh but not
> always.
> Hey and BTW, there's libtool. You can forget half of what you
> learned, use
> LT_* instead. Ah and did I tell you that the examples presented so
> far are
> too simple? Use subdirectories in real projects!
> 
> What? You're confused? Must be you!
> 
> Maybe if a crack wrote a simple tutorial beginning at the top. Using
> all the
> "highest" level APIs only, never mentioning that there are actually
> three or
> four or five tools involved and why and how they work. If the most
> common
> needs were addressed with examples without taking a detour to explain
> how
> the electrons flow through your semiconductors. If the examples were
> uniform
> and ready for real-world projects. If only reasonably modern
> platforms were
> addressed, leaving the exotic and the antique to the freaks. Maybe
> /then/
> auto* tools wouldn't be that "scary".
> 
> Better yet. Make it (the knowledge about, NOT the use of) obsolete
> for 95%
> of the projects. Who codes in assembler, after all? /Generate/ this
> ugly
> stuff!
> 
> Kdevelop is my hope.
> 
> ;-)
> 
> -- Mark
> 
> 
> 
> 
> -
> to unsubscribe from this list send an email to
> kdevelop-devel-request at kdevelop.org with the following body:
> unsubscribe »your-email-address«

__________________________________________________
Do You Yahoo!?
Find the one for you at Yahoo! Personals
http://personals.yahoo.com

-
to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
unsubscribe »your-email-address«



More information about the KDevelop-devel mailing list