public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: "R. Diez" <rdiezmail-newlib@yahoo.de>
To: joel@rtems.org
Cc: Matthew Joyce <matthew.joyce@embedded-brains.de>,
	Newlib <newlib@sourceware.org>
Subject: Re: Question about autoreconf to regenerate configuration files
Date: Fri, 21 Jan 2022 17:09:50 +0100	[thread overview]
Message-ID: <41deefa7-d1ae-18f2-6a8e-25e002d85ed6@yahoo.de> (raw)
In-Reply-To: <CAF9ehCX=+beX6Ar4YjYh-3F15szxNgPZAK-e5JqxyWCaEjEfSg@mail.gmail.com>


> [...]
> The bootstrap time was large enough to
> negatively impact our ability to do automated regression testing.

A very long bootstrap time could be an issue.

However, compilation time normally outweighs by far the Autotools regeneration step. Is that a problem in Newlib at the moment?


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

Newlib users will use different compiler versions, different GNU Make versions, etc. I do not understand why fixing the Autotools versions would be an advantage for Newlib.

If you are trying to reproduce some weird build bug, you can ask the developer to use particular versions of the Autotools. If you are trying to get reproducible builds, your build script can make sure it is using the same Autools versions every time. That is not hard to achieve with this script of mine:

https://github.com/rdiez/Tools/tree/master/Autotools


> 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.

Users would not normally download the Git Head, but some release tarball. That tarball should then have all the Autotools-generated files. This way, all users will build with the same Autotools-generated files.

Only Newlib developers working against Git Head would have to deal with the Autotools. And that is not normally a problem, if the build system is healthy, like it should be.

Checking the Autotools files into the repository has several drawbacks. We have seen 2 of them again recently, and I am sure that we will see more in the future. I understand that the developer doing the much-needed Autotools clean-up, Mike Frysinger, also advised against checking in those files.

If Newlib wishes to depart from best practice, it would be nice to know the concrete issues in the context of this project, and not just some general "all solutions in this area seem to suck" justification.

Regards,
   rdiez

  reply	other threads:[~2022-01-21 16:09 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-21 12:32 Matthew Joyce
2022-01-21 13:44 ` Corinna Vinschen
2022-01-21 15:02 ` R. Diez
2022-01-21 15:37   ` Joel Sherrill
2022-01-21 16:09     ` R. Diez [this message]
2022-01-21 22:09       ` Mike Frysinger
2022-01-21 23:08         ` Joel Sherrill
2022-01-22 21:20         ` R. Diez
2022-01-23  0:17           ` Joel Sherrill
2022-01-23 16:57             ` R. Diez
2022-01-26 10:19               ` Mike Frysinger
2022-01-30 22:22                 ` R. Diez
2022-01-23  7:29           ` Mike Frysinger
2022-01-26 10:02         ` Mike Frysinger
2022-02-17  5:18           ` Mike Frysinger
2022-02-17  6:56             ` Sebastian Huber
2022-02-20  9:51             ` R. Diez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41deefa7-d1ae-18f2-6a8e-25e002d85ed6@yahoo.de \
    --to=rdiezmail-newlib@yahoo.de \
    --cc=joel@rtems.org \
    --cc=matthew.joyce@embedded-brains.de \
    --cc=newlib@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).