Re: rm -f # no more args failure?
On 12 Dec 2021 16:17, Karl Berry wrote: > Does anyone here use or know of an active system where plain > rm -f > with no arguments fails? I mean, exits with bad status? > > We are considering changing Automake to assume this works, > although we'd provide for a workaround just in case, something like > make RM_F="rm -f nosuchfile" > > But if there are still active systems where it's a problem, > we will probably make no change. since automake made `rm -f` check fatal at configure-time and asked people to file bug reports, they've been collected here as blockers: https://debbugs.gnu.org/10828 there's only 3 reports filed from the last 10 years. -mike signature.asc Description: PGP signature
Re: [PATCH] configure: handle KCC on case-insensitive filesystems
Subject: [PATCH] configure: handle KCC on case-insensitive filesystems Pushed with doc tweak per Jim. Thanks.
bug#21336: [PATCH] configure: handle KCC on case-insensitive filesystems
Subject: [PATCH] configure: handle KCC on case-insensitive filesystems Pushed with doc tweak per Jim. Thanks.
Re: [PATCH] gitignore: update
> +*~ > +.#* Suggest also adding \#*# (emacs autosave files) and .*.sw[op] (vim autosave files). Pushed, thanks.
Re: [PATCH] m4: replace AC_DIAGNOSE with m4_warn
--- a/m4/obsolete.m4 +++ b/m4/obsolete.m4 Pushed, thanks. grep -r shows more occurrences of AC_DIAGNOSE in m4/init.m4 (seems straightforward) and mkdirp.m4, which seems to be a decision that was undone, but I don't have the energy to try to find the discussion now to see how to "adjust [the] warning message". Maybe you could take a look when you have a chance? --thanks, karl.
Re: rm -f # no more args failure?
On Sun, 12 Dec 2021, Karl Berry wrote: Does anyone here use or know of an active system where plain rm -f with no arguments fails? I mean, exits with bad status? I thought that systems deriving from OpenSolaris (e.g. Illumos, OpenIndiana, etc.) had that issue until ksh93 was fixed recently. However, testing in an empty directory on a system without the upated ksh93 this looks ok to me: $ rm -f ; echo $? 0 $ rm -f * ; echo $? 0 so the issue that Automake encountered before must not be exactly that. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: [PATCH 1/2] m4: warn when AM_SILENT_RULES default is used
> To help ease people into enabling silent rules by default, warn if FWIW, I don't agree with any of these silent-rule patches, for all the reasons Zack explained. They just seem like they are inflicting pain on existing users with no return benefit. -k
rm -f # no more args failure?
Does anyone here use or know of an active system where plain rm -f with no arguments fails? I mean, exits with bad status? We are considering changing Automake to assume this works, although we'd provide for a workaround just in case, something like make RM_F="rm -f nosuchfile" But if there are still active systems where it's a problem, we will probably make no change. Thanks, Karl
bug#21336: [PATCH] configure: handle KCC on case-insensitive filesystems
On Thu, Dec 9, 2021 at 10:56 PM Mike Frysinger wrote: > This fixes https://debbugs.gnu.org/21336. On macOS 10.10, there seems Note that I still see kcc on 12.0.1 > to be a kerberos tool installed as "kcc" which breaks the check. > > Also resync with latest autoconf which searches for clang++ too. > > * configure.ac: Skip KCC check on case-insensitive filesystems. Add > clang++ to the C++ search list. Modulo that log nit, this commit looks fine. Thanks!
Re: [PATCH] configure: handle KCC on case-insensitive filesystems
On Thu, Dec 9, 2021 at 10:56 PM Mike Frysinger wrote: > This fixes https://debbugs.gnu.org/21336. On macOS 10.10, there seems Note that I still see kcc on 12.0.1 > to be a kerberos tool installed as "kcc" which breaks the check. > > Also resync with latest autoconf which searches for clang++ too. > > * configure.ac: Skip KCC check on case-insensitive filesystems. Add > clang++ to the C++ search list. Modulo that log nit, this commit looks fine. Thanks!
Re: [PATCH] m4: replace AC_DIAGNOSE with m4_warn
On Sat, Dec 11, 2021 at 10:07 PM Mike Frysinger wrote: > AC_DIAGNOSE was marked obsolete with autoconf-2.62 in 2008. > > * m4/obsolete.m4: Change AC_DIAGNOSE to m4_warn. > --- > m4/obsolete.m4 | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/m4/obsolete.m4 b/m4/obsolete.m4 > index 79f3b234bfc5..bf3b68271673 100644 > --- a/m4/obsolete.m4 Looks fine. Thanks!
Re: [PATCH 1/2] m4: warn when AM_SILENT_RULES default is used
On Sat, Dec 11, 2021 at 10:09 PM Mike Frysinger wrote: > To help ease people into enabling silent rules by default, warn if > a package doesn't make an explicit selection. > --- > NEWS | 10 ++ > m4/silent.m4 | 6 +- > 2 files changed, 15 insertions(+), 1 deletion(-) > > diff --git a/NEWS b/NEWS > index fb05ee219708..282eb9277a3d 100644 > --- a/NEWS > +++ b/NEWS > @@ -3,6 +3,16 @@ please see NEWS-2.0 and start following the advice there now. > > > > +New in 1.17: > + > +* Future changes > + > + - In preparation for silent rules being enabled by default, issue warnings > +when a default has not been selected. This is shown to developers (who > +run automake for their package) and for users (who run ./configure). This seems sensible for the interim. Do all of the self tests pass as-is, or do they all need to be adjusted to suppress the new diagnostic?
Re: [RFC/PATCH] m4: enable silent build rules by default
On Sun, Dec 12, 2021 at 7:14 AM Zack Weinberg wrote: > > On Sun, Dec 12, 2021, at 1:10 AM, Mike Frysinger wrote: > > On 07 Dec 2021 21:58, Zack Weinberg wrote: > >> On Tue, Dec 7, 2021, at 9:49 PM, Mike Frysinger wrote: > >> > This has been available since automake 1.11 released over a decade > >> > ago. Let's flip the default to enable silent builds by default. > >> > >> Please don't *ever* make this change. It is absolutely essential that the > >> default build output be verbose, else anyone who's stuck trying to debug a > >> build on a CI server that they have no direct access to is in a world of > >> hurt. > > > > people can trivially add --disable-silent-rules to their configure > > invocations. > > i really don't think this is as onerous as you make it out to be. > > I can tell you've never had this experience, or you wouldn't say that. And > probably you wouldn't be proposing this patch in the first place :-P > > There's some piece of software. You don't know how its build system works, > and the process of configuring and building it is hidden behind at least one > layer of packaging automation. It's got a bug in its build, but only on some > architecture you do not have shell access to, only some CI system that you do > not administer and whose only interface is "upload software, get back logs > minutes to hours later." It builds Just Fine on your computer. > > The logs you got back from your first attempt to build it are useless because > the equivalent of --enable-silent-rules is on by default. > > You spend anywhere between five minutes and an hour figuring out which build > system the software uses, what its equivalent of --disable-silent-rules is, > and where to poke that into the packaging automation. You throw another > build at the CI. Half an hour later you get back logs that are *still* > useless because you misunderstood where the poke goes. > > You tinker with it on your computer and get the poke into the right place and > get back logs that are not useless. You throw another build at the CI. Half > an hour later you get back logs that are *still* useless because the CI uses > a slightly different build process (think pbuilder vs sbuild) and that means > the poke is still not in the right place. > > This cycle can go on for DAYS if you're sufficiently unlucky. > > Yes, an awful lot of this is the fault of the packaging automation and the CI > in question. But Automake can't do shit about that. But what Automake *can* > do is avoid making the situation even worse, by ... sticking to what it > already does: verbose builds by default. > > - > > I'd like to generalize the above point a little. I saw someone (possibly > you) advocating for --enable-silent-rules by default because it makes it less > likely for actual warnings and errors to get lost amid a flood of chatter. > This is absolutely true. I use --enable-silent-rules all the time on the > software that I work on frequently, because in *that* situation the chatter > *is* irrelevant -- I already have the build environment set up correctly, I'm > not going to need to figure out why the C compiler can't find > or anything like that. And even with compilation-mode doing the actual work > of scanning for warnings, the terse log *is* easier on my poor tired brain. > > --enable-silent-rules is good for day-to-day maintenance. > --disable-silent-rules, on the other hand, is what people want when they have > no prior familiarity with some software, and they're just trying to fix one > bug, because in that situation they may *not* have things set up right and > the build system hiding details of what it's actually doing is more likely to > be aggravating than not. > > I'm arguing that the out-of-the-box, default behavior of Automake-driven > builds should optimize for the experience of people who are just trying to > fix one bug, *not* for the experience of day-to-day maintainers. That might > sound backward but think about it. Day-to-day maintainers have the time and > the incentive to set up customizations. They have plenty of other reasons to > learn the ins and outs of the configuration process. It's *easy* to get in > the habit of typing `./configure --enable-silent-rules` instead of just > `./configure` once you know that that does a thing you like. The > out-of-the-box experience does not *need* to be tuned for regular > maintainers' convenience. Rather, it should be tuned for the convenience of > people who have never tried to build the software before and do *not* have > the time or patience to mess with the defaults. Hi Zack, Mike and Karl, I argue that we must optimize for the vastly-more-numerous cohort: consumers who are *NOT* in the unusual position of debugging some arcane build failure whose origin is masked by using AM_SILENT_RULES([yes]). I've specified AM_SILENT_RULES([yes]) in any package I've ever tended, and don't recall having or hearing
Re: [PATCH 1/2] m4: warn when AM_SILENT_RULES default is used
On Sun, Dec 12, 2021, at 1:09 AM, Mike Frysinger wrote: > To help ease people into enabling silent rules by default, warn if > a package doesn't make an explicit selection. -1 for the same reason that changing the default is a bad idea. If we are to make *any* change in this area I would advocate instead for a step in the opposite direction: remove the DEFAULT argument from AM_SILENT_RULES. The default is hardcoded to "no". In other words, individual packages are no longer allowed to make the user-hostile decision of switching the default to "yes". In addition to the ergonomics benefit, taking away that knob would smooth the path to having the AM_SILENT_RULES *feature* be enabled by default: that is, all automake-using packages get the --enable-silent-rules switch and the makefile machinery to back it up, without having to mention AM_SILENT_RULES in configure.ac. zw
Re: [RFC/PATCH] m4: enable silent build rules by default
On Sun, Dec 12, 2021, at 1:10 AM, Mike Frysinger wrote: > On 07 Dec 2021 21:58, Zack Weinberg wrote: >> On Tue, Dec 7, 2021, at 9:49 PM, Mike Frysinger wrote: >> > This has been available since automake 1.11 released over a decade >> > ago. Let's flip the default to enable silent builds by default. >> >> Please don't *ever* make this change. It is absolutely essential that the >> default build output be verbose, else anyone who's stuck trying to debug a >> build on a CI server that they have no direct access to is in a world of >> hurt. > > people can trivially add --disable-silent-rules to their configure > invocations. > i really don't think this is as onerous as you make it out to be. I can tell you've never had this experience, or you wouldn't say that. And probably you wouldn't be proposing this patch in the first place :-P There's some piece of software. You don't know how its build system works, and the process of configuring and building it is hidden behind at least one layer of packaging automation. It's got a bug in its build, but only on some architecture you do not have shell access to, only some CI system that you do not administer and whose only interface is "upload software, get back logs minutes to hours later." It builds Just Fine on your computer. The logs you got back from your first attempt to build it are useless because the equivalent of --enable-silent-rules is on by default. You spend anywhere between five minutes and an hour figuring out which build system the software uses, what its equivalent of --disable-silent-rules is, and where to poke that into the packaging automation. You throw another build at the CI. Half an hour later you get back logs that are *still* useless because you misunderstood where the poke goes. You tinker with it on your computer and get the poke into the right place and get back logs that are not useless. You throw another build at the CI. Half an hour later you get back logs that are *still* useless because the CI uses a slightly different build process (think pbuilder vs sbuild) and that means the poke is still not in the right place. This cycle can go on for DAYS if you're sufficiently unlucky. Yes, an awful lot of this is the fault of the packaging automation and the CI in question. But Automake can't do shit about that. But what Automake *can* do is avoid making the situation even worse, by ... sticking to what it already does: verbose builds by default. - I'd like to generalize the above point a little. I saw someone (possibly you) advocating for --enable-silent-rules by default because it makes it less likely for actual warnings and errors to get lost amid a flood of chatter. This is absolutely true. I use --enable-silent-rules all the time on the software that I work on frequently, because in *that* situation the chatter *is* irrelevant -- I already have the build environment set up correctly, I'm not going to need to figure out why the C compiler can't find or anything like that. And even with compilation-mode doing the actual work of scanning for warnings, the terse log *is* easier on my poor tired brain. --enable-silent-rules is good for day-to-day maintenance. --disable-silent-rules, on the other hand, is what people want when they have no prior familiarity with some software, and they're just trying to fix one bug, because in that situation they may *not* have things set up right and the build system hiding details of what it's actually doing is more likely to be aggravating than not. I'm arguing that the out-of-the-box, default behavior of Automake-driven builds should optimize for the experience of people who are just trying to fix one bug, *not* for the experience of day-to-day maintainers. That might sound backward but think about it. Day-to-day maintainers have the time and the incentive to set up customizations. They have plenty of other reasons to learn the ins and outs of the configuration process. It's *easy* to get in the habit of typing `./configure --enable-silent-rules` instead of just `./configure` once you know that that does a thing you like. The out-of-the-box experience does not *need* to be tuned for regular maintainers' convenience. Rather, it should be tuned for the convenience of people who have never tried to build the software before and do *not* have the time or patience to mess with the defaults. zw
Re: [PATCH] gitignore: update
On Sun, Dec 12, 2021, at 1:07 AM, Mike Frysinger wrote: > Ignore all *~ files as editors like to create them, as do some > autotool steps. This also matches what autoconf is doing. ... > +*~ > +.#* Suggest also adding \#*# (emacs autosave files) and .*.sw[op] (vim autosave files). zw
