[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Autoconf Digest, Vol 104, Issue 14

From: David A. Wheeler
Subject: Re: Autoconf Digest, Vol 104, Issue 14
Date: Wed, 19 Dec 2012 13:53:35 -0500 (EST)

Bob Friesenhahn <address@hidden>:
> It is pretty common that the person trying to eliminate a warning does 
> not understand the code well enough to understand the consequences of 
> their action or is interested in a quick fix.

But one reason this happens is that the original developer never saw the 
warning.  If warnings are *on* by default, the original developer is far more 
likely to see and respond to them.  Nowadays, developers pull from some repo 
and use autoconf to set up a working version.  If the defaults don't turn on 
warnings, nothing else will either.

Bob Friesenhahn <address@hidden>:
> I understand your concern and the reasoning, but these sort of options 
> are highly platform/target/distribution specific.  It is easy to 
> create packages which fail to build on many systems.  Later, the baked 
> in settings of somewhat dated distribution tarballs may not meet 
> current standards.
> Surely it is better to leave this to OS distribution maintainers who 
> establish common rules for OS packages and ensure that options are 
> applied in a uniform and consistent manner.

The whole *point* of autoconf is to make it easy to distribute packages that 
work on various systems.  We have many, many examples where the "OS 
distribution maintainers" don't use what's available.  Perhaps even more 
importantly, "Joe User" who installs software from source code will *NOT* know 
how to enable them, unless they happen to be in the site or system-wide config 
files.  But since these capabilities aren't baked into autoconf, they are 
unlikely to be in the system-wide config files either.

Paul Eggert:
> Abstractly, I think Autoconf machinery to support security
> checking is a good idea, but the devil is in the details.

Amen to that, of course :-).

--- David A. Wheeler

reply via email to

[Prev in Thread] Current Thread [Next in Thread]