Re: Question about autoreconf to regenerate configuration files

Joel Sherrill <[email protected]>
Newsgroups gmane.comp.lib.newlib
Message-ID <CAF9ehCX=+beX6Ar4YjYh-3F15szxNgPZAK-e5JqxyWCaEjEfSg@mail.gmail.com>
On Fri, Jan 21, 2022 at 9:03 AM R. Diez via Newlib
<[email protected]> wrote:
>
>
> > [...]
> > but I have also unwittingly modified well over 100 files (numerous Makefile.in, aclocal.m4, and configure files).
> > I'd like to understand: Is this expected or desirable? Should I not be using autoreconf for this?
>
> This is another drawback of checking into the repository the files generated by the Autotools, see this e-mail:
>
> require autoconf-2.69 exactly
> Wed Jan 12 20:01:01 GMT 2022
> https://sourceware.org/pipermail/newlib/2022/018866.html
>
> See also the answer from Mike Frysinger about this problem:
>
> require autoconf-2.69 exactly
> Wed Jan 12 21:37:22 GMT 2022
> https://sourceware.org/pipermail/newlib/2022/018867.html

Over at RTEMS when we used autotools, we didn't commit most of the
output.  Our tools included the preferred autoconf/automake versions.

We did put the generated acinclude.m4 for the list of BSPs in git. But
even on that, we had issues because the order of BSPs would vary
depending on which host generated it. Ultimately, we eliminated that
file.

The bootstrap time after checkout was quite large compared to the
actual compilation time. The bootstrap time was large enough to
negatively impact our ability to do automated regression testing. We
have switched away from autotools.

One of our long standing concerns with letting users generate was
reproducibility. How do you know that two end users end up with the
same generated output?

It's a pain to put the generated output in git but at least it saves
generating it and ensures it is the same for all users building.

All solutions in this area seem to suck. It is only a matter of degree.

--joel

> Regards,
>    rdiez
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.