Generated files in Git

[Sebastian Huber]

On 05/16/2012 03:41 PM, Joel Sherrill wrote:
> On 05/16/2012 05:35 AM, Sebastian Huber wrote:
>> Hello,
>>
>> we have found some files that are generated during build, and thus should not
>> be under configuration management (CM).
> When I saw the subject, I thought we would be discussing putting
> autotools generated files in git. It would seem to address two
> issues brought up in the "Build Issues" thread:
>
> + switching branches in git
> + need to bootstrap from clone

I guess merging will be problematic if we add these generated Autotools files.

>> If you put the RTEMS source tree under CM with for example Rational Synergy,
>> then this leads to problems.
>
> It just isn't a CM style issue. It is building from CD/DVD.
>
> GCC had a recent discussion about trying to build from a read-only
> tree. It was due to some autotools changes and their impact.
> There wasn't a problem but they didn't want the autotools changes
> to break this.

Yes, basically it is building from a read-only source tree.

>
>
>>
>> So, when trying to build from a Rational Synergy work area, which by default is
>> write protected, we get some errors. There are .c files, that are generated by
>> running sed on a .in file, but that fails because the generated files were in
>> the original Git repository, and thus migrated into Synergy. Actually only the
>> Makefile.am and the .in should be under CM.
> Are you putting autotools generated files in Synergy?
>
> This is basically trying to build from a read-only source tree. GCC
> considers some files in the tree to "maintainer updated" and thus would
> be OK to be in git and in the tree in this mode.

Yes, this "maintainer updated" is all right (e.g. we have this with the 
preinstall.am files).

>>
>> As you know, there are two flavours of CM systems, CVS style (modify-commit)
>> and RCS style (lock-modify-commit). Synergy is “RCS style”, while Git is CVS
>> style. That is why we have bigger problems with this inconsistency.
>>
>> The “wrong” files are
>>
>> - 3 .c files in rtems/testsuites/libtests/complex/
>>
>> - 1 .c file in rtems/testsuites/libtests/math/
>>
>> - 1 .c file in rtems/testsuites/libtests/mathf/
>>
>> - 1 .c file in rtems/testsuites/libtests/mathl/
> c/src/ada-tests/sptests/sp19 should be on your list.
>
> What about the documentation? The version.texi file is generated
> based on timestamp on the master file of the manual changes. Those
> are in git also.
>
> And autotools generated files if that should be up for discussion.

I would not add them.

>>
>> Also, the Makefile does not clean the generated files on “make distclean”.
> If we added autotools generated files, then we would have the same issue.
> Plus distclean is not supposed to remove configure and Makefile.in.
>>
>> How to fix this? Remove the generated files from Git and add a distclean hook?
>
> Should the files be generated on the fly and placed in the build directory?
>
> distclean is supposed to take you back to a "fresh tarball" state. If they
> are not in git and generated into the build directory, then that would be
> meet that requirement.
>
> But I don't think that covers every case.

I have to figure out why these *.c files in the tests are re-generated.

-- 
Sebastian Huber, embedded brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax     : +49 89 18 90 80 79-9
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.