Re: autoconf-refactor done

From: Kinkie <gkinkie_at_gmail.com>
Date: Wed, 4 Aug 2010 23:19:21 +0200

On Wed, Aug 4, 2010 at 9:29 PM, Alex Rousskov
<rousskov_at_measurement-factory.com> wrote:
> On 08/04/2010 11:32 AM, Kinkie wrote:
>>
>> Hi all,
>>   I've pushed the hopefully final revision of the autoconf-refactor
>> branch to launchpad (lp:~kinkie/squid/autoconf-refactor/)
>> It's a bit out of date with trunk, I plan to update it tomorrow
>> evening, after that it can be merged anytime.
>> It's a 50k lines patch, so I doubt it can be posted for review here..
>>
>> In order to check it, I've matched that (at least with the default
>> configure switches) the generated .h files and configure logs are
>> consistent with those generated by trunk.
>> The branch passes the build-test on my ubuntu box.
>
> Please post the proposed commit message with the description of changes.
> This may help with the review.

Purpose of the branch is to try and give an uniform style to the
configure.in and auxiliary scripts.
Except for what was already merged there are no further behaviour changes.

Main changes are:
- definition of a common naming convention for shell variables
- definition of auxiliary macros to deal with common constructs
(--enable-* and --with-*)
- definition of auxiliary macros to deal with autoconf defines
- reindent to increase readability (no automated tools exist unfortunately)
- general streamlining of the configure.in process logic, to clarify
as much as possible what is the flow that leads to enabling or
disabling a certain feature (e.g. IO loop engine selection)
- modularization of configure.in by moving many inline operations to
external macros included from auxiliary scripts; aim is to host the
logic in configure, and the mechanisms in auxiliary scripts.
- simplify as possible, by removing redundant checks
- adhere to common configure.in conventions and increase portability
(e.g. by moving away from test -z and test -n constructs, in favour of
safer alternatives)

All those goals require a few exceptions to manage the enormous
variety of configuration options squid has; the result is IMVHO much
more readable and easily extendable than the initial version.

-- 
    /kinkie
Received on Wed Aug 04 2010 - 21:19:29 MDT

This archive was generated by hypermail 2.2.0 : Fri Aug 06 2010 - 12:00:03 MDT