Generated files in Git

[Joel Sherrill]

On 05/16/2012 08:50 AM, Sebastian Huber wrote:
> 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.
Why? GCC, binutils, etc all include their autotools generated files. They
really don't change that often.

And when the project decides to upgrade autotools, there is a discussion
followed by a large commit.

I don't think merging will be impacted.
>
>>> 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.
>
In some cases, the tests instantiate templates to avoid duplication.

Often this can be done with macros -- I'm thinking of the spfatal*
tests as an example. But other times, it simply can't be.

-- 
Joel Sherrill, Ph.D.             Director of Research&   Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
     Support Available             (256) 722-9985