Generated files in Git
sebastian.huber at embedded-brains.de
Wed May 16 13:50:39 UTC 2012
On 05/16/2012 03:41 PM, Joel Sherrill wrote:
> On 05/16/2012 05:35 AM, Sebastian Huber wrote:
>> 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
>> 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.
More information about the devel