@MSGID: <20230825113441.899@kylheku.com> 235974e0
@REPLY:
<87a5ufhtk5.fsf@doppelsaurus.mobileactivedefense.com> 7170fe93
@REPLYADDR Kaz Kylheku <864-117-4973@kylheku.com>
@REPLYTO 2:5075/128 Kaz Kylheku
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: <20230825113441.899@kylheku.com>
@RFC-References: 1@dont-email.me>
1@dont-email.me> <87wmxps26h.fsf@bsb.me.uk> 1@dont-email.me>
<87r0nxrvm1.fsf@bsb.me.uk> 1@dont-email.me> <87zg2jrk7t.fsf@bsb.me.uk>
1@dont-email.me> <87lee2qz5v.fsf@bsb.me.uk> 1@dont-email.me>
<20230823195415.19d4c01e0cb2ca57faf92c07@g{oogle}mail.com> 2@dont-email.me> 1@dont-email.me>
<20230824083325.525@kylheku.com> 1@dont-email.me> GMN3.79590@fx16.iad>
1@dont-email.me> <20230824160017.406@kylheku.com>
<87edjrhz1d.fsf@doppelsaurus.mobileactivedefense.com> <20230825095521.754@kylheku.com>
<87a5ufhtk5.fsf@doppelsaurus.mobileactivedefense.com>
@TZUTC: -0000
@PID: slrn/pre1.0.4-9 (Linux)
@TID: FIDOGATE-5.12-ge4e8b94
On 2023-08-25, Rainer Weikusat <rweikusat@talktalk.net> wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>> That maintains the repository in a configurable, buildable state
>> for a downstream user who deosn`t have AutoTools installed.
>
> Downstream users are a problem I don`t have.
>
> Nevertheless, I think a
> repository is something supposed to be used for development, ie, it
> should be expected that users of it will make changes to .ac and .am
> files.

A repository should easily support all parties. Someone who wants to
build the program for their own use, package it for a distro, or work on
it.

Downstream users are a problem that open source projects have.

> If the files generated from these are also in the repository,
> nuisance git dances will have to be performed to deal with them and this
> will also cause nuisance merge conflicts for updates.

If you merge parallel changes to a primary file from which a secondary
file is generated, you must regenerate the secondary file. The seconary
file should not be merged. (That would be editing, and generated files
are "generated, do not edit", right?)

The problem is not that you get a conflict in the secondary file.  The
problem is that you might *not* get a conflict in it, but (1) it`s a bad
merge (even though the merge of the primary file is good) and (2) it
happens that the badly merged secondary has a newer timestamp than the
primary, so the build system doesn`t notice that it needs to be
regenerated.

So, in fact, it`s probably a good idea for a generated file to include
some boilerplate header with the time and date (or hash of the primary
file), so that it will cause a merge conflict on puprpose, preventing a
silent bad merge!

E.g.:

   //
   // foo.c: generated from foo.x: do not edit!
   //
   // If you get a merge conflict in the following line, do not try
   // to resolve it (see "do not edit!) above; regenerate the file using
   // "make foo.c":
   //
   // 0828aa34e7d8bf5c8007e897ce12459912e7ee491e1c17377432c8bf204704be

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- slrn/pre1.0.4-9 (Linux)
 * Origin: A noiseless patient Spider (2:5075/128)
SEEN-BY: 5001/100 5005/49 5010/352 5015/255 5019/40
5020/715 848 1042 4441
SEEN-BY: 5020/12000 5030/49 1081 5075/128
@PATH: 5075/128 5020/1042 4441