HEADSUP: Adding auto*generated files to rtems-4.11's git

[Pavel Pisa]

On Thursday 26 July 2012 17:45:24 Ralf Corsepius wrote:
> On 07/26/2012 05:13 PM, Pavel Pisa wrote:
> > Generated files in GIT usually cause more problems than they solve
> > in long term.
>
> They don't cause any problems, if you ignore the dynamics  and treat
> them static. This means, don't use "--enable-maintainer-mode" and all
> these files will be treated as static and time stamps being ignored.

But then you declare GIT tree as a place intended for other then developers.
"--enable-maintainer-mode is really usable if you expect to
modify Makefile.am or add BSPs etc. And because generated files
contain (most probably) some lines which slightly differs between
checkouts according used tolls, directories and dates then generated
files would not be same and there would be ballast in commints which
would make merging much harder.

> > for newcomers sometimes as well. In RTEMS case, how big
> > are problems with use of pre-installed auto-tool on different
> > distributions.
>
> Using a distribution's preinstalled autotools has _never_ been supported
> by RTEMS and will never work in general.
>
> Whether using them will work in a particular set is random luck. They
> may work, they may work in some cases etc.
...
> Also, let me mention: I _KNOW_ using the upcoming automake-1.13 will not
> work with RTEMS.

That all looks quite badly. But anyway separation of clean sources
and generated files is nice thing to have. It is the best base
for merging, switching branches etc. and I expect that
with mixed sources with make targets files in repo make controlled
build can break quite horribly after checkouts and "make clean"
is required much more often.

I see two (not ideal still) ways how that can be solved.
Both based on two branches. One with clean sources and another
with sources including generated (distribution) files. The second branch
(in same or other GIT repo) can be maintained automatically by merging
from the first and running auto* and committing result. This has
disadvantage that the second repo would be full of merges - after each
commit or if rerun for example daily then after each day. Other option
is to use build the second branch by feeding commits to it through
patches or may it be rebases, this would lead to clean history without
merges with generated files. But that setup is susceptible to breakage.

So none of these solutions is ideal.

On the other hand it is not big problem to get clean sources GIT
history from branch with generated files with help of
"git filter-branch".

Other option is to demand automake-rtems4.11 (rtems4.11-automake)
or something like that for RTEMS build, break if not found
and enforce that everybody install such auto-tools build
same way as *-*-rtems4.11-gcc is mandatory for RTEMS users.

Best wishes,

              Pavel