[PATCH] fix datarootdir warnings by autoconf 2.61

[Andreas Ericsson]

Ethan Galstad wrote:
> Hendrik Baecker wrote:
>> Andreas Ericsson schrieb:
>>> Ton Voon wrote:
>>>> Hi Hendrik,
>>>>
>>>> On 30 May 2009, at 20:39, Hendrik Baecker wrote:
>>>>
>>>>> After upgrading from autoconf 2.59 to 2.61 a new
>>>>> option was givven: --datarootdir
>>>>> The datarootdir replaces the old htmldir/datadir in
>>>>> subst.in and Makefile.in files.
>>>>>
>>>>> This patch fixes some minor makefile cleanups for the new t-tap
>>>>> directory. A 'make distclean' will result in a really clean
>>>>> directory.
>>>> I've applied the t-tap cleanups - thanks.
>>>>
>>>> I haven't applied the datarootdir option. I'm not sure what we are 
>>>> doing regarding autoconf and other dev tools.
>>>>
>>>> Ethan, Andreas, any thoughts? For the plugins, we list the developer 
>>>> requirements and we do not commit any files that are auto generated.
>>>>
>>> I agree 100% with not committing autogenerated files. Such files should
>>> ofcourse be included in releases, but having them in the repo is just so
>>> much dead weight.
>> So you want one extra step for those guys who are dealing with the
>> latest head?
>> IMO the change frequency of autogenerated files like configure isn't
>> too high to save larger commit diffs caused by this fileclass.
>>
>> Where do you see a problem after changing some code which needs an
>> update of the configure.in stuff to rebuild configure by the developer
>> and check this in?
>> As long all dev members are using the same autoconf version I don't
>> see a big problem.
>>
>> Is it safer to don't commit those file for the development process?
>>
>> -
>> Hendrik
> 
> 
> The only thing anyone should be mucking with when making changes is
> configure.in.  The "configure" script has been in CVS for ages, and
> there's no reason to take it out now.  I don't really think there's an
> absolute requirement that all the core devs use the same autoconf
> version, as long as its somewhat recent.  Makes it a hell of a lot
> easier to just to a CVS checkout and run ./configure, which helps with
> automated scripts.
> 

There are two problems with this.

The first is patch review. If someone makes a change to configure.in
and re-generates configure from it with a more recent version of autoconf
the patch will be *huge*, but the actual change might be 3-4 lines.

The second is human error. If someone makes a change to configure.in but
forgets to re-generate configure.in, users will be using the (possibly)
flawed configure script without knowing it.

Personally I like what the plugins do about this, shipping a microscopic
script that just issues the autoconf commands so one doesn't have to
remember them.

I don't care much either way though, but I might ask configure.in hackers
to send the diff to configure.in separately for reviewing purposes.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects