Kaz Kylheku <864-117-4973@kylheku.com> writes:

[...]

> If you're unfortunate enough to work with AutoTools, then for pete's
> sake, generate the configure script, and the Makefile.in and whatnot,
> and check them into the repository. Do that every time they change.

I routinely remove these from any source tree I seriously need to work
with because sooner or later, changes to all the autosomething files
will become necessary and intermediate autosomething files generated
from the others tend to get in the way then.

On Fri, 25 Aug 2023 17:22:54 +0100
Rainer Weikusat <rweikusat@talktalk.net> wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>
> [...]
>
> > If you're unfortunate enough to work with AutoTools, then for pete's
> > sake, generate the configure script, and the Makefile.in and whatnot,
> > and check them into the repository. Do that every time they change.
>
> I routinely remove these from any source tree I seriously need to work
> with because sooner or later, changes to all the autosomething files
> will become necessary and intermediate autosomething files generated
> from the others tend to get in the way then.

git supports the gitignore file to cover such situations :
https://git-scm.com/docs/gitignore .So you can add all the automatically
generated files to a gitgnore file.

On 2023-08-25, Spiros Bousbouras <spibou@gmail.com> wrote:
> On Fri, 25 Aug 2023 17:22:54 +0100
> Rainer Weikusat <rweikusat@talktalk.net> wrote:
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>
>> [...]
>>
>> > If you're unfortunate enough to work with AutoTools, then for pete's
>> > sake, generate the configure script, and the Makefile.in and whatnot,
>> > and check them into the repository. Do that every time they change.
>>
>> I routinely remove these from any source tree I seriously need to work
>> with because sooner or later, changes to all the autosomething files
>> will become necessary and intermediate autosomething files generated
>> from the others tend to get in the way then.
>
> git supports the gitignore file to cover such situations :
> https://git-scm.com/docs/gitignore .So you can add all the automatically
> generated files to a gitgnore file.

I think, gitignore doesn't cover the situation when some of those files
are tracked in git, but you disagree.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2023-08-25, Rainer Weikusat <rweikusat@talktalk.net> wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>
> [...]
>
>> If you're unfortunate enough to work with AutoTools, then for pete's
>> sake, generate the configure script, and the Makefile.in and whatnot,
>> and check them into the repository. Do that every time they change.
>
> I routinely remove these from any source tree I seriously need to work
> with because sooner or later, changes to all the autosomething files
> will become necessary and intermediate autosomething files generated
> from the others tend to get in the way then.

If you have to change the configuration, you have to make a commit for
that and check in the updated files.

That maintains the repository in a configurable, buildable state
for a downstream user who deosn't have AutoTools installed.

If you use the same version of the tools as what was previously used,
then the diffs in those files will be minimized.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Kaz Kylheku <864-117-4973@kylheku.com> writes:
> On 2023-08-25, Rainer Weikusat <rweikusat@talktalk.net> wrote:
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>
>> [...]
>>
>>> If you're unfortunate enough to work with AutoTools, then for pete's
>>> sake, generate the configure script, and the Makefile.in and whatnot,
>>> and check them into the repository. Do that every time they change.
>>
>> I routinely remove these from any source tree I seriously need to work
>> with because sooner or later, changes to all the autosomething files
>> will become necessary and intermediate autosomething files generated
>> from the others tend to get in the way then.
>
> If you have to change the configuration, you have to make a commit for
> that and check in the updated files.
>
> 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. 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.

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

On Thu, 24 Aug 2023 18:29:02 GMT, scott@slp53.sl.home (Scott Lurndal)
wrote in <OjNFM.897908$GMN3.79590@fx16.iad>:

> The default rules built into make(1) include a rule like
>
> %.o: %.c
> $(CC) $(CFLAGS) -o $@ -c $<

A lot of times, for simple one-off projects, I don't
need a Makefile.

Assuming a valid source file "try.c", I can
type "make try" and get an executable
called "try".

_ _ _ _ _ _ _
$ echo "int main(){ return 0; }" > try.c
$ make try
cc try.c -o try
$ make CFLAGS=-O3 try
make: 'try' is up to date.
$ rm try
$ make CFLAGS=-O3 try
cc -O3 try.c -o try
$ echo 'CFLAGS=-O3' > Makefile
$ rm try
$ make try
cc -O3 try.c -o try
_ _ _ _ _ _ _

I may be mistaken, but I'm pretty sure this works
in any modern POSIX environment.

Folks are calling it "Unix/Linux" software. But a subset of
that is POSIX, and a POSIX environment on Windows should let
you build some of the same software. (I used to use Cygwin
for that, before I jumped ship completely from Windows.)

And I used the package manager to install autoconf,
which gave me the aclocal command.

Bart:

If you're cloning a git repository on an autoconf package,
expect to run ./autogen.sh -- the included "configure" script
probably isn't set up for Windows. (Guessing.)

And for autogen to work, you'll need the autoconf
developer environment. If you're on Windows,
a working autoconf would seem to be important here,
since that gives you the "aclocal" command that is part
of the process -- and which sets up the configure script
for your environment.

(Just be glad you aren't using imake...)

--
-v

On 2023-08-24, vallor <vallor@cultnix.org> wrote:
> If you're cloning a git repository on an autoconf package,
> expect to run ./autogen.sh -- the included "configure" script
> probably isn't set up for Windows. (Guessing.)

An Autoconf ./configure script must work on any platform
to which the program can reasonably be considered to be ported,
plus some on which it has not been tried.

> And for autogen to work, you'll need the autoconf
> developer environment.

That defeats the whole purpose of Autoconf.

Many GNU programs are like this, unfortunately.

When they make a release, they generate the configure script and then
tar everything up. So what they are shipping is not a clean snapshot
from their repository!

Conversely, when you clone their repositories, you are not getting the
same thing as a release tarball.

You're assumed to be a developer who is willing to install the right
version of AutoCrap this and AutoPoop that,and then run "make boostrap"
or whatever.

If you're unfortunate enough to work with AutoTools, then for pete's
sake, generate the configure script, and the Makefile.in and whatnot,
and check them into the repository. Do that every time they change.

Make it so you can cut a release using "git tag" and nothing else.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Kaz Kylheku <864-117-4973@kylheku.com> writes:
> On 2023-08-25, Rainer Weikusat <rweikusat@talktalk.net> wrote:

[configure & friends in git]

>> 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?)

Precisely. But git will try to merge them nevertheless and the resulting
merge conflicts need to be dealt with somehow. A good way to do so is

Never check anything into git which is supposed to generated from
something else also checked into git. In case someone else did this,
remove it.

On 2023-08-29, Rainer Weikusat <rweikusat@talktalk.net> wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>> On 2023-08-25, Rainer Weikusat <rweikusat@talktalk.net> wrote:
>
> [configure & friends in git]
>
>>> 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?)
>
> Precisely. But git will try to merge them nevertheless and the resulting
> merge conflicts need to be dealt with somehow. A good way to do so is
> Never check anything into git which is supposed to generated from
> something else also checked into git. In case someone else did this,
> remove it.

By and large, and by default, we should follow the configuration
management principle that secondary/derived objects are not put into
version control, only primary ones. This principle agrees with what you
are saying. When not sure, don't check in the derived object.

There are exceptions though.

The real criterion is which way life is easier.

The answer will be different based on whether the software is
distributed in source code form to large numbers of downstream users, or
whether it is something built in-house (e.g. proprietary software).

In a source distribution scenario I find these benefits

- every commit of the repo can be checked out and built; the correct
generated files are just there.

- a release can be cut with just:

git tag <release-tag>; git push origin tag <release-tag>

there is no special baseline.

These outweigh the minor issue of merges in generated files.

- If I don't have the generated file (it is not in version control),
it will have to be generated anyway.

- If I have the generated file in version control, and it has been
subject to a merge, it has to be blown away and generated.

This is almost the same except for the extra effort to be aware
of the situation and not accidentally check in the file when it
was silently merged without conflicts.

Tiny effort for a palpable payoff: I can do a "git bisect" and have
the correct versions of generated files at every commit I visit!

If you check out a baseline from ten years ago, you get the
correct ten-year-old configure script or y.tab.c, which
were generated with the version of the generators used at the
time.

Checking in generated files helps with reproducible builds;
to reproduce an old build, you just need the old compilers,
not the old parser generator, AutoTools and whatever else.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Kaz Kylheku <864-117-4973@kylheku.com> writes:
> On 2023-08-29, Rainer Weikusat <rweikusat@talktalk.net> wrote:
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>> On 2023-08-25, Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>
>> [configure & friends in git]

[...]

>> Never check anything into git which is supposed to generated from
>> something else also checked into git. In case someone else did this,
>> remove it.
>
> By and large, and by default, we should follow the configuration
> management principle that secondary/derived objects are not put into
> version control, only primary ones. This principle agrees with what you
> are saying. When not sure, don't check in the derived object.
>
> There are exceptions though.

[easily building old releases]

> If you check out a baseline from ten years ago, you get the
> correct ten-year-old configure script or y.tab.c, which
> were generated with the version of the generators used at the
> time.

Hmm ... in my opinion, the chances that a ten year old version of
anything non-trivial will compile, let alone work, on a current Linux
system are exceedingly slim and an old system will have the old tools
available.

Rainer Weikusat <rweikusat@talktalk.net> writes:
>Kaz Kylheku <864-117-4973@kylheku.com> writes:
>> On 2023-08-29, Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>>> On 2023-08-25, Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>>
>>> [configure & friends in git]
>
>[...]
>
>>> Never check anything into git which is supposed to generated from
>>> something else also checked into git. In case someone else did this,
>>> remove it.
>>
>> By and large, and by default, we should follow the configuration
>> management principle that secondary/derived objects are not put into
>> version control, only primary ones. This principle agrees with what you
>> are saying. When not sure, don't check in the derived object.
>>
>> There are exceptions though.
>
>[easily building old releases]
>
>> If you check out a baseline from ten years ago, you get the
>> correct ten-year-old configure script or y.tab.c, which
>> were generated with the version of the generators used at the
>> time.
>
>Hmm ... in my opinion, the chances that a ten year old version of
>anything non-trivial will compile, let alone work, on a current Linux
>system are exceedingly slim and an old system will have the old tools
>available.

That hasn't been my experience. I've been building xrn, z.b., since
first building it for SVr3.2/X11R3 on a M88100. It builds on current
linux distributions (much like all the other Xaw clients).

Weyland may end that run, however, sadly.