[PATCH] fix datarootdir warnings by autoconf 2.61

[Andreas Ericsson]

Hendrik Baecker wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>  
> 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?

Yes and no. Those who want to *use* it should be able to get a
snapshot of the latest code where this file is pre-generated.
Developers who actually *work* on the files really shouldn't be
too fuzzed about running "make configure" or whatever command we
decide to implement to create it.

> IMO the change frequency of autogenerated files like configure isn't
> too high to save larger commit diffs caused by this fileclass.
> 

I disagree. Putting autogenerated files under version control is
*never* a good idea. Change frequency has nothing to do with it.

> 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?

For one thing, the patches generally become hard to review, and
especially so if the developer who re-generated the file is using
a different version of the generating tool to generate it. A 40k
diff-file is *not* fun to look at.

> As long all dev members are using the same autoconf version I don't
> see a big problem.
> 

So you're fine with requiring everyone to use the same toolchain, but
not with requiring core hackers to run one small command before they
can test-compile the code?

Besides, it's quite simple to add make-rules that rebuilds the
configure file and re-runs configure whenever there are changes to
configure.in (or however that arcane stuff works).

> Is it safer to don't commit those file for the development process?
> 

Yes. Otherwise you could have misguided people (me for example)
making changes to the generated file and committing them, only
to be thoroughly lost when those changes disappear when someone
does some other change in the right place later on and re-generates
the file. It's just stupid.

-- 
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