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