* newlib not building (needs aclocal) @ 2022-02-22 11:57 Richard Earnshaw 2022-02-22 22:11 ` [PATCH/committed] libgloss: enable maintainer mode support Mike Frysinger 2022-02-23 6:01 ` newlib not building (needs aclocal) Brian Inglis 0 siblings, 2 replies; 8+ messages in thread From: Richard Earnshaw @ 2022-02-22 11:57 UTC (permalink / raw) To: Mike Frysinger, newlib Mike, I think something you've changed is forcing the newlib build to now need a local installation of automake. This wasn't needed before unless you were updating the makefiles locally. CDPATH="${ZSH_VERSION+.}:" && cd [...]/libgloss && /bin/bash [...]/missing aclocal-1.15 -I . -I .. -I ../config [...]/missing: line 81: aclocal-1.15: command not found WARNING: 'aclocal-1.15' is missing on your system. You should only need it if you modified 'acinclude.m4' or 'configure.ac' or m4 files included by 'configure.ac'. Did you leave something out of a commit somewhere? If not, how can this be fixed so that we don't need automake during normal builds from the repo? R. PS While I appreciate what you're trying to do here, the timing couldn't be worse given that we're trying to stabilize a GCC release and all my builds are breaking at present. ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH/committed] libgloss: enable maintainer mode support 2022-02-22 11:57 newlib not building (needs aclocal) Richard Earnshaw @ 2022-02-22 22:11 ` Mike Frysinger 2022-02-23 11:26 ` Richard Earnshaw 2022-02-23 6:01 ` newlib not building (needs aclocal) Brian Inglis 1 sibling, 1 reply; 8+ messages in thread From: Mike Frysinger @ 2022-02-22 22:11 UTC (permalink / raw) To: newlib; +Cc: Richard.Earnshaw Use AM_MAINTAINER_MODE so devs have to opt-in to automatic rebuilds of autotools. This matches what newlib (and most every other GNU toolchain package) does with automake. --- libgloss/Makefile.in | 9 +++++---- libgloss/aclocal.m4 | 36 ++++++++++++++++++++++++++++++++++++ libgloss/configure | 34 ++++++++++++++++++++++++++++++++++ libgloss/configure.ac | 1 + 4 files changed, 76 insertions(+), 4 deletions(-) diff --git a/libgloss/configure.ac b/libgloss/configure.ac index b5a0fce08c9b..ec2a49e03704 100644 --- a/libgloss/configure.ac +++ b/libgloss/configure.ac @@ -12,6 +12,7 @@ AC_PROG_INSTALL AC_CANONICAL_SYSTEM AM_INIT_AUTOMAKE([foreign no-dist no-define subdir-objects 1.15.1]) +AM_MAINTAINER_MODE AM_SILENT_RULES(yes) if test -z "${with_multisubdir}"; then -- 2.34.1 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH/committed] libgloss: enable maintainer mode support 2022-02-22 22:11 ` [PATCH/committed] libgloss: enable maintainer mode support Mike Frysinger @ 2022-02-23 11:26 ` Richard Earnshaw 0 siblings, 0 replies; 8+ messages in thread From: Richard Earnshaw @ 2022-02-23 11:26 UTC (permalink / raw) To: Mike Frysinger, newlib Thanks, Mike. On 22/02/2022 22:11, Mike Frysinger wrote: > Use AM_MAINTAINER_MODE so devs have to opt-in to automatic rebuilds > of autotools. This matches what newlib (and most every other GNU > toolchain package) does with automake. > --- > libgloss/Makefile.in | 9 +++++---- > libgloss/aclocal.m4 | 36 ++++++++++++++++++++++++++++++++++++ > libgloss/configure | 34 ++++++++++++++++++++++++++++++++++ > libgloss/configure.ac | 1 + > 4 files changed, 76 insertions(+), 4 deletions(-) > > diff --git a/libgloss/configure.ac b/libgloss/configure.ac > index b5a0fce08c9b..ec2a49e03704 100644 > --- a/libgloss/configure.ac > +++ b/libgloss/configure.ac > @@ -12,6 +12,7 @@ AC_PROG_INSTALL > > AC_CANONICAL_SYSTEM > AM_INIT_AUTOMAKE([foreign no-dist no-define subdir-objects 1.15.1]) > +AM_MAINTAINER_MODE > AM_SILENT_RULES(yes) > > if test -z "${with_multisubdir}"; then ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: newlib not building (needs aclocal) 2022-02-22 11:57 newlib not building (needs aclocal) Richard Earnshaw 2022-02-22 22:11 ` [PATCH/committed] libgloss: enable maintainer mode support Mike Frysinger @ 2022-02-23 6:01 ` Brian Inglis 2022-02-23 11:33 ` Richard Earnshaw 1 sibling, 1 reply; 8+ messages in thread From: Brian Inglis @ 2022-02-23 6:01 UTC (permalink / raw) To: newlib On 2022-02-22 04:57, Richard Earnshaw wrote: > I think something you've changed is forcing the newlib build to now need > a local installation of automake. This wasn't needed before unless you > were updating the makefiles locally. > > CDPATH="${ZSH_VERSION+.}:" && cd [...]/libgloss && /bin/bash > [...]/missing aclocal-1.15 -I . -I .. -I ../config > [...]/missing: line 81: aclocal-1.15: command not found > WARNING: 'aclocal-1.15' is missing on your system. > You should only need it if you modified 'acinclude.m4' or > 'configure.ac' or m4 files included by 'configure.ac'. > > Did you leave something out of a commit somewhere? If not, how can this > be fixed so that we don't need automake during normal builds from the repo? > > R. > > PS While I appreciate what you're trying to do here, the timing couldn't > be worse given that we're trying to stabilize a GCC release and all my > builds are breaking at present. If you need stability, shouldn't you freeze your newlib pull at year end 4.2.0 20211231 484d2eb snapshot, earlier about 2021-09-06 522cdab, just before Mike started his optimization and cleanup marathon, or maybe add an arm-gcc-dev(-11?) tag at some point in there? Do you think perhaps devs doing extended or extensive work should create their own newlib, topic, or remote tracking branches (as Cygwin devs do for major work - see summary page heads or git ls-remote --heads --sort=-creatordate | head) and commit work there, perhaps merging back to master at intermediate points, or even not until complete? -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: newlib not building (needs aclocal) 2022-02-23 6:01 ` newlib not building (needs aclocal) Brian Inglis @ 2022-02-23 11:33 ` Richard Earnshaw 2022-02-24 7:07 ` Mike Frysinger 0 siblings, 1 reply; 8+ messages in thread From: Richard Earnshaw @ 2022-02-23 11:33 UTC (permalink / raw) To: newlib, Brian Inglis On 23/02/2022 06:01, Brian Inglis wrote: > On 2022-02-22 04:57, Richard Earnshaw wrote: > >> I think something you've changed is forcing the newlib build to now >> need a local installation of automake. This wasn't needed before >> unless you were updating the makefiles locally. >> >> CDPATH="${ZSH_VERSION+.}:" && cd [...]/libgloss && /bin/bash >> [...]/missing aclocal-1.15 -I . -I .. -I ../config >> [...]/missing: line 81: aclocal-1.15: command not found >> WARNING: 'aclocal-1.15' is missing on your system. >> You should only need it if you modified 'acinclude.m4' or >> 'configure.ac' or m4 files included by 'configure.ac'. >> >> Did you leave something out of a commit somewhere? If not, how can >> this be fixed so that we don't need automake during normal builds from >> the repo? >> >> R. >> >> PS While I appreciate what you're trying to do here, the timing >> couldn't be worse given that we're trying to stabilize a GCC release >> and all my builds are breaking at present. > > If you need stability, shouldn't you freeze your newlib pull at year end > 4.2.0 20211231 484d2eb snapshot, earlier about 2021-09-06 522cdab, just > before Mike started his optimization and cleanup marathon, or maybe add > an arm-gcc-dev(-11?) tag at some point in there? Well for testing gcc-12 a freeze for gcc-11 is not very helpful. Newlib doesn't have release branches (not really sure why not, especially when there are potential security issues to deal with), and while I could freeze against specific tags, that would mean I never test tip-of-tree newlib. Fortunately, over the years newlib has been very stable and it has been rare for there to be much breakage (at least, breakage that prevents building at all). > > Do you think perhaps devs doing extended or extensive work should create > their own newlib, topic, or remote tracking branches (as Cygwin devs do > for major work - see summary page heads or git ls-remote --heads > --sort=-creatordate | head) and commit work there, perhaps merging back > to master at intermediate points, or even not until complete? > There might be a case for this, particularly for disruptive changes. It's a matter of balance, given the size of the newlib project. As I said before, I fully support modernizing newlib's make structure, it's just a little unfortunate that it's being done during the run-up to gcc-12. R. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: newlib not building (needs aclocal) 2022-02-23 11:33 ` Richard Earnshaw @ 2022-02-24 7:07 ` Mike Frysinger 2022-02-24 7:11 ` Mike Frysinger 0 siblings, 1 reply; 8+ messages in thread From: Mike Frysinger @ 2022-02-24 7:07 UTC (permalink / raw) To: Richard Earnshaw; +Cc: newlib, Brian Inglis [-- Attachment #1: Type: text/plain, Size: 3224 bytes --] On 23 Feb 2022 11:33, Richard Earnshaw wrote: > On 23/02/2022 06:01, Brian Inglis wrote: > > On 2022-02-22 04:57, Richard Earnshaw wrote: > >> PS While I appreciate what you're trying to do here, the timing > >> couldn't be worse given that we're trying to stabilize a GCC release > >> and all my builds are breaking at present. > > > > If you need stability, shouldn't you freeze your newlib pull at year end > > 4.2.0 20211231 484d2eb snapshot, earlier about 2021-09-06 522cdab, just > > before Mike started his optimization and cleanup marathon, or maybe add > > an arm-gcc-dev(-11?) tag at some point in there? > > Well for testing gcc-12 a freeze for gcc-11 is not very helpful. Newlib > doesn't have release branches (not really sure why not, especially when > there are potential security issues to deal with), and while I could > freeze against specific tags, that would mean I never test tip-of-tree > newlib. i think this is conflating things a bit. tot testing gcc against tot newlib is helpful for both projects. we want that. but if gcc is preparing a release branch, it should be freezing against a specific newlib tag (the latest at the time of that branch cut). users of a gcc release will also be grabbing newlib releases and expecting that they work together. that might mean there's still disruption for devs during the release cycle -- tot gcc hadn't been tested against the latest newlib release previously, so bugs could pop up. but users are going to see those same bugs, so it's not like they're "false" failures. throwing builders at it would help (have tot test against tot newlib and the last newlib release), but i suspect that isn't worth the effort for the same reasons you mention -- the project normally doesn't move that fast, and the number of active devs is kind of low. > > Do you think perhaps devs doing extended or extensive work should create > > their own newlib, topic, or remote tracking branches (as Cygwin devs do > > for major work - see summary page heads or git ls-remote --heads > > --sort=-creatordate | head) and commit work there, perhaps merging back > > to master at intermediate points, or even not until complete? > > There might be a case for this, particularly for disruptive changes. > It's a matter of balance, given the size of the newlib project. practically speaking, i don't think topic branches would help that much as you highlight -- the newlib project, and number of projects/devs, is much too small to get a good signal back. it would require people to opt-in to the branch, as well as configure the various builders out there to use it. that seems pretty unlikely. which means once the topic branch is merged back into master, everything blows up. except instead of little scattered fires that are easier to pin to specific commit ranges, everything is on fire, perhaps for more than one reason, and requires multiple bisects over weeks/months of work. i'd like to think that for the regressions i've introduced (and fixed), i've made up for it with better comments & documentation. so the next person who touches things doesn't fall into the same pits. -mike [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: newlib not building (needs aclocal) 2022-02-24 7:07 ` Mike Frysinger @ 2022-02-24 7:11 ` Mike Frysinger 2022-02-24 9:08 ` Corinna Vinschen 0 siblings, 1 reply; 8+ messages in thread From: Mike Frysinger @ 2022-02-24 7:11 UTC (permalink / raw) To: Richard Earnshaw, newlib, Brian Inglis [-- Attachment #1: Type: text/plain, Size: 712 bytes --] On 24 Feb 2022 02:07, Mike Frysinger wrote: > practically speaking, i don't think topic branches would help that much as > you highlight -- the newlib project, and number of projects/devs, is much > too small to get a good signal back. which isn't to say i'm against them. i asked in a previous thread a while back about newlib policies around creating branches like this so i could push my local state for people to peek at, but didn't get a response. so i assumed it was undesired or not allowed. at this point, i've got maybe 5 patches for libgloss (update toolchain settings as has been done in newlib already) & 5 for newlib (finish libc conversion to top-level like libm) before i call it quits. -mike [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: newlib not building (needs aclocal) 2022-02-24 7:11 ` Mike Frysinger @ 2022-02-24 9:08 ` Corinna Vinschen 0 siblings, 0 replies; 8+ messages in thread From: Corinna Vinschen @ 2022-02-24 9:08 UTC (permalink / raw) To: newlib On Feb 24 02:11, Mike Frysinger wrote: > On 24 Feb 2022 02:07, Mike Frysinger wrote: > > practically speaking, i don't think topic branches would help that much as > > you highlight -- the newlib project, and number of projects/devs, is much > > too small to get a good signal back. > > which isn't to say i'm against them. i asked in a previous thread a while > back about newlib policies around creating branches like this so i could > push my local state for people to peek at, but didn't get a response. so > i assumed it was undesired or not allowed. You can create and destroy topic branches, e.g. git checkout -b topic/drop-all-32bit-targets These can be force pushed and generally worked on without generating mails to newlib-cvs. We're using them in Cygwin as well if something isn't supposed to go into master just yet. Corinna ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-02-24 9:08 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-02-22 11:57 newlib not building (needs aclocal) Richard Earnshaw 2022-02-22 22:11 ` [PATCH/committed] libgloss: enable maintainer mode support Mike Frysinger 2022-02-23 11:26 ` Richard Earnshaw 2022-02-23 6:01 ` newlib not building (needs aclocal) Brian Inglis 2022-02-23 11:33 ` Richard Earnshaw 2022-02-24 7:07 ` Mike Frysinger 2022-02-24 7:11 ` Mike Frysinger 2022-02-24 9:08 ` Corinna Vinschen
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).