Pregenerated files: repo freeze and discourse

[Chris Johns]

On 1/08/12 5:09 PM, Ralf Corsepius wrote:
> On 08/01/2012 08:03 AM, Chris Johns wrote:
>> On 1/08/12 1:44 PM, Ralf Corsepius wrote:
>>> On 07/31/2012 07:41 PM, Gedare Bloom wrote:
>
>>> The sizes of the repos hardly has any impact on using the repos.
>>>
>>
>> Ralf, based on what ?
>
> It a one time thing affecting "cloning". It does not affect using.
>

This is what we are talking about. Cloning has slowed. Lets not hide the 
issues. It is matter of discussing them and determining what there 
effects are.

>
>>>> So far I have not seen very clear explanation why adding these
>>>> generated files to the git repository is the best solution long-term
>>>> for RTEMS.
>>> I already tried to explain this before.
>>>
>>> The advantages are:
>>> - No need for "bootstrap".
>>
>> Does this mean the bootstrap is going away as a result of this ?
> No. It only means bootstrap has become a maintainer thing.

I tend to associate git with maintainers and not user.

>
> Users will on need it on very rare occasions.
>

Is this something that has changed ?

>>> - Makes bugs in configuration files more visible.
>>
>> Could you explain this ? I find the complexity of the autoconf and
>> automake set up we have in RTEMS difficult to follow so I fail to
>> understand how I am support to come to this conclusion.
>>
>>> - Makes user mistakes in configuration files more visible.
>>
>> Could you please explain this ?
>
> One such case is changes silently not getting promoted, e.g. changes to
> configure.ac into configure-scripts.
>
> With configure in git you'd immediately notice this in "git diffs"
>
> Historic example for such a case in RTEMS is bspopts.h-generation. There
> have been cases, when syntax errors in configure.ac had caused silently
> broken configure scripts, which then had produced broken bspopts.h.in.
> These errors had managed to get away unnoticed longer periods, because
> they only affected the generated files.
>

If there is a bug it should have been caught with testing. We should be 
more concerned about this than this issue.

I am not sure about your point. Yes it can pick up a problem, but 
equally if we have a tested system with no bootstrap because we "trust" 
the git held generated source and a configure.ac exists that generates 
different source then we have another type of problem. If I have to 
bootstrap to check I do not see what we have gained.

>
>>> ...
>>>
>>>
>>>> The main problem we face is that switching branches with
>>>> generated files is troublesome,
>>> This is simply not true.
>>>
>>>   Switching branches is supposed to wipe all such files away to replace
>>> them with the versions on the "switched-to branch".
>>>
>>> I.e. try working on local branches with all changes kept in git.
>>> When changing configure.acs/Makefiles.am, manually regenerate the files
>>> using autoreconf and commit the resulting changes.
>>>
>>
>> Gedare was commenting on the issues with the files not in git.
>
> Again, with the new scheme, there are "not any files not in git"
>

Therefore we must have a "trusted" state and that is a concern to me.

>>> People need to go through a learning curve and adopt their habits.
>>> that's all.
>>
>> Could you please provide documentation on how we are suppose to use this
>> ?
> I really don't know what to answer.

What you list below is a start. Thanks. Please understand there are many 
users where this is helpful.

>
> It all condenses down into:
> - Make sure to have the nominal versions of the autotools in $PATH.
> - Make sure to have your Makefile.ins and configures in git.
> - After having run a toplevel ./bootstrap git diff must be empty.
>
> Then work with RTEMS as before.
>

I need to update my autoconf/automake because they have changed to check.

>> For example can we mix generated files from different hosts ?
> Sure. The files in question are _generated sources_, ie. they are
> supposed to be identical on all hosts (Otherwise they can't be part of a
> VCS).
>
>> Does a
>> change in any autotools require all generated files to be updated ?
> Yes. Each version of rtems requires a specific set of autotools.
>
> This is not new and had applied ever since RTEMS uses autotools.
>

I was asking if autoconf or automake change we need to regenerate 
everything.

>> There are many more questions.
> Did you actually try to build RTEMS since my commits?

Build or develop ?

> I can not avoid to
> presume "no", because otherwise you'd not raise these comments.

I am rather busy at the moment and I will get to them in my time. Joel 
is away on holiday.

You could have presented these changes on your personal repo and we 
could have tested them without git commits needing to stop in case we 
need to revert until we agree they are acceptable or they are dropped.

Chris