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

Markus Kuehni markus.kuehni at trilab.ch
Wed Nov 14 16:05:31 UTC 2001


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«



More information about the KDevelop-devel mailing list