autotools and programming style (was: Remove cdrtools)
Am Montag 14 August 2006 23:27 schrieb Steve Greenland:
> On 14-Aug-06, 15:59 (CDT), Michael Poole <mdpoole@troilus.org> wrote:
> > Wouter Verhelst writes:
> > > In the case of autotools, the fact is that usually it's configure.ac or
> > > Makefile.am being horribly broken, rather than the autotools.
> >
> > In my experience, this is greatly exacerbated and perhaps even
> > primarily due to older versions of autotools encouraging or requiring
> > behavior that later versions of autotools declare to be broken.
>
> That's *one* of the problems. If you only ever compile on Linux or *BSD,
> it might seem the most common.
See, nobody uses AC_PREREQ and still complains.
> The *real* problem with the whole autotools disaster is that it promotes
> a braindead idea of how to achieve portability: a #ifdef branch for
> every different system (or library version, or whatever), strewn
> throughout the entire codebase.
Even when looking at somewhat related systems like *BSD and Linux, even
opening an bluetooth RFComm socket _must_ use #ifdefs because this small OSS
community cannot communicate about simple stuff like:
- placing the bluetooth.h header file
- naming values in the headerfile
- names of the address structure and its elements.
The NetBSD guys soemwhat saw this and hacked in some bluez compatibility. But
the normal way is different on Linux, FreeBSD and NetBSD (Solaris not
competing here at all ;)).
They all do the same but lack off communication and stubborness got us all
into this situation. And loose standards cause this kind of things.
Autotools is _not_ the cause for this and the ifdefs that it proposes are
mostly short.
> Real portability involves understanding
> your target systems, learning where the rough edges and corner cases
> are, and developing proper abstractions to work around them.
Real life portability is often done for systems that you
- did not install yourself
- do not have steady access to or no access at all (only using documentation)
or is done by people that somehow hacked into your peace of software to make
it work in their systems (with absolutely no design goal in mind while
porting).
> Oh, and actually learning the standard version of the language (if there is
> one), and being able to distinguish between "this is what the language
> says it will do" and "works for me".
You mean the difference between manpages-posix-dev (in non-free) and
manpages-dev (in main)? The first is not proposed by Debian (I still don't
get why anone would want to change a standards document as not changing it is
the whole purpose of its existence.)
http://www.opengroup.org helps a lot.
> The sad thing is that Henry Spencer warned us 15 years ago[1], and
> nobody learned a damn thing.
Interesting lecture.
HS
Reply to: