Hi,
  +1. I'm convinced that the upsides far outweigh the downsides.

On Tue, Apr 30, 2013 at 12:42 PM, Amos Jeffries <[email protected]> wrote:
> On 29/04/2013 1:07 p.m., Amos Jeffries wrote:
>>
>> One of the outstanding issues in ./configure has been the dependence on
>> standalone bash scripts for detecting whether a helper is able to build or
>> not.
>> The problem is that they are standalone so we cannot re-use test results
>> already existing in configure.ac in the scripts and vice-versa.
>> We also encounter some errors (as seen in the bugs about SASL location) as
>> a side effect of different tests being run.
>>
>> To resolve this I propose changing the config.test files into small M4
>> scriptlets which can be included directly into configure at bootstrap time.
>>
>> Pros:
>>  * we gain a huge amount of information from existing configure.ac tests
>>  * we gain ability to run autoconf checks in the test scriptlets
>>  * we can push test results back to the main configure.ac cache from the
>> scriptlets for faster overall process
>
>
> The attached patch implements the above. I managed to avoid the expected
> problem.
>
> The nature of m4 macros however has added two smaller ones in its place.
> Both well-known issues with m4_include() expansion:
>  * the macro is expanded in-place without scoping separation.
>  So any brokenness in the child scripts will be a little harder to identify
> and may result in breakage of modues other than the one whose child script
> was the cause.
>
>  * the macro takes literal arguments without variable expansion.
>  So a "full" path relative to the main configure.ac script is required in
> every include. Meaning the modules.m4 file cannot simply sub-include using
> the $helper script variable, but must be a full expansion of the modules
> set.
>
> I believe these are well outweighted by the Pros above however. Already this
> patch is catching fails-to-build error in PAM, SASL, and LDAP far better on
> several systems just by way of the macro usage in the required.m4 files.
>
> Amos



-- 
    /kinkie

Reply via email to