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 [email protected]
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.
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]