ANN: Upgrade rtems-4.11-autoconf to autoconf-2.69

Gedare Bloom gedare at rtems.org
Wed May 23 17:12:51 UTC 2012


On Wed, May 23, 2012 at 12:42 PM, Ralf Corsepius
<ralf.corsepius at rtems.org> wrote:
> On 05/23/2012 06:28 PM, Gedare Bloom wrote:
>>
>> On Wed, May 23, 2012 at 12:11 PM, Ralf Corsepius
>> <ralf.corsepius at rtems.org>  wrote:
>>>
>>> On 05/23/2012 05:59 PM, Gedare Bloom wrote:
>>>>
>>>> how come when i do bootstrap -c I do not have a "clean" checkout?
>>>>
>>>> ./bootstrap -c
>>>> removing automake generated Makefile.in files
>>>> removing configure files
>>>> removing aclocal.m4 files
>>>>
>>>> git status
>>>> # On branch master
>>>> #
>>>> # Changed but not updated:
>>>> #   (use "git add/rm<file>..." to update what will be committed)
>>>> #   (use "git checkout --<file>..." to discard changes in working
>>>> directory)
>>>> #
>>>> #       deleted:    config.guess
>>>> #       deleted:    config.sub
>>>> #       deleted:    install-sh
>>>> #       deleted:    missing
>>>> #
>>>
>>> There are two perspectives on this:
>>>
>>> 1. We always want them to be sync'ed with the versions in automake.
>>>
>>> =>  ./bootstrap (actually automake) needs to update them.
>>> Afterwards, they must match with the versions in git.
>>>
>>> This is what is currently implemented.
>>>
>>>
>> I see, so ./bootstrap should (and does) restore the versions in git.
>> I'm not sure why these files are even in git then if we use approach
>> #1?
>
> They are required to be part of the source-tree for the autotools to work
> correctly.
>
> (They are not generated, they are copied - This might be difficult to
> understand, but is an essential difference)
>
>
>>> 2. We want to maintain them manually.
>>> =>    bootstrap -c must not remove them and ./bootstrap must not re-add
>>> or
>>> update them.
>>>
>> It seems like #2 would mean we should keep the files in git.
>
> Let me put it this way, #2 needs further inspection when more
> generated/copied files will enter the repository.
>
> My plan is to gradually add more of them to git to make people gradually
> familar with the impact and the mindset behind this.
>
Well, speaking for myself, I would prefer to be explained ahead of
time rather than trying to understand as things are gradually rolled
out and having to question it each time another copied (or generated)
file is added to the repository.

> Ralf
>




More information about the devel mailing list