bug#20713: aclocal/tar.m4 and solaris 5.10
On 21 Feb 2022 16:26, Karl Berry wrote: > should we change "unknown" to $GID & $UID respectively ? > > I guess it couldn't hurt, although I doubt it makes any difference in > practice. i feel like you just accidentally wrote Automake's motto :p > if test $am_uid = "unknown"; then > > Don't we usually avoid quoting constant strings? I.e.: > if test "$am_uid" = unknown; then tbh, i have no idea what the quoting style/preference is in the GNU world, if there actually is one. i know i see plenty of underquoting, and plenty of odd `test` styles that aren't well documented (like using the "x" prefix to avoid testing empty strings). > AC_MSG_WARN([ancient id detected; assuming current UID is ok, but > dist-ustar might not work]) > > "Might"? Either it works or it doesn't? Anyway, who ever uses ustar? > Never seen it. we won't know whether it works until we actually try to create an archive. and depending on the system, that might be too late (see below). > Anyway, seems like such a warning "might" be useful when producing an > archive with automake (running make dist), but not when running > configure. When merely doing "./configure && make", ustar is irrelevant. sure, but we don't probe tools during `make dist`, we do it during configure > Anyway #2, I think the chances of someone wanting to produce a ustar > archive on a system with old id is zero. > > Thus I suggest just fixing the syntax stuff and letting it go at that. ustar might not be the most common nowadays. i think there's merit to issuing a warning so we aren't in the situation of people reporting bugs that `make dist` threw a weird error they don't understand, and if their system was in such a bad state, why weren't they warned about it ? in fact, isn't that what led to these checks in the first place ? we have reports from users: https://bugs.gnu.org/8343 https://bugs.gnu.org/13588 > the point of the checks isn't just to annoy the user. > > No :)? That's what it seems like. Helpful to the package developer; > annoyance to the configure user. -k configure user can (re)create dist tarballs too. not the common flow, but it can be helpful when you're hacking on a system and want to pull the state back out. or when trying to comply with the GPL requirements :). the reason your system hit this code path is because it wasn't able to handle the formats earlier in the list (gnutar in this case). -mike signature.asc Description: PGP signature
bug#53340: [PATCH] python: use xargs -n when uninstalling files
- $(am__cd) "$$dir" && $(am__rm_f) $$files; }; \ + $(am__cd) "$$dir" && echo $$files | $(am__xargs_n) 40 $(am__rm_f); }; \ Looks good to me, FWIW. -k
bug#20713: aclocal/tar.m4 and solaris 5.10
should we change "unknown" to $GID & $UID respectively ? I guess it couldn't hurt, although I doubt it makes any difference in practice. if test $am_uid = "unknown"; then Don't we usually avoid quoting constant strings? I.e.: if test "$am_uid" = unknown; then AC_MSG_WARN([ancient id detected; assuming current UID is ok, but dist-ustar might not work]) "Might"? Either it works or it doesn't? Anyway, who ever uses ustar? Never seen it. Anyway, seems like such a warning "might" be useful when producing an archive with automake (running make dist), but not when running configure. When merely doing "./configure && make", ustar is irrelevant. Anyway #2, I think the chances of someone wanting to produce a ustar archive on a system with old id is zero. Thus I suggest just fixing the syntax stuff and letting it go at that. the point of the checks isn't just to annoy the user. No :)? That's what it seems like. Helpful to the package developer; annoyance to the configure user. -k
bug#17614: parallel compilation fails
On 21 Feb 2022 12:15, Peter Johansson wrote: > On 25/1/22 16:24, Mike Frysinger wrote: > > On 19 Jan 2022 18:32, Peter Johansson wrote: > >> On 19/1/22 18:10, Mike Frysinger wrote: > >>> assuming it still fails with Automake 1.16 ... > >> > >> I'll test when I'm out of this semi-lockdown and have access to a > >> computer with more CPUs. > >> > >>> can you link to the project for us to take a look ? > >> Tar file is available from here > >> > >> https://sourceforge.net/projects/libyat/ > >> > >> and subversion repo from here if that's preferable > >> > >> https://dev.thep.lu.se/yat/svn/trunk > > i grabbed the 0.19 release. perhaps unsurprising, nothing stood out to me > > related to the error above. you didn't have any recursive makes or any code > > that seemed to override the dep generation or create conflicting outputs. > > > > if you can reproduce it, get a full log and send it over, and include the > > config.log file i think. something like `make -O -j... >& log`. > > > > the error you quoted is part of automake's dependency generation. it's very > > weird that you'd get an error about .Tpo & .Plo being the same file when the > > rule that creates them creates the .Tpo then moves it to .Plo. there is no > > place where we ever write to .Plo otherwise. > > I've tried this now and in short I cannot reproduce it. I tried with > Automake 1.13 now (bcs it's what available by default) and ran both on > current code and an older branch, but nothing that looks like this. Many > things have changed since 2014 when this was filed and I think for > example that the file system was much slower back then. I suspect that > the problem was that the same file was compiled twice, but since I can't > reproduce it, it's impossible to determine whether it was due to > problematic Makefile.am, generated Makefile, or possibly behaviour of > make, so if not already closed, please close this and I'll report back > if something similar returns. np. feel free to ping/reopen if something does turn up. -mike signature.asc Description: PGP signature
bug#17614: parallel compilation fails
Hi Mike, On 25/1/22 16:24, Mike Frysinger wrote: On 19 Jan 2022 18:32, Peter Johansson wrote: On 19/1/22 18:10, Mike Frysinger wrote: assuming it still fails with Automake 1.16 ... I'll test when I'm out of this semi-lockdown and have access to a computer with more CPUs. can you link to the project for us to take a look ? Tar file is available from here https://sourceforge.net/projects/libyat/ and subversion repo from here if that's preferable https://dev.thep.lu.se/yat/svn/trunk i grabbed the 0.19 release. perhaps unsurprising, nothing stood out to me related to the error above. you didn't have any recursive makes or any code that seemed to override the dep generation or create conflicting outputs. if you can reproduce it, get a full log and send it over, and include the config.log file i think. something like `make -O -j... >& log`. the error you quoted is part of automake's dependency generation. it's very weird that you'd get an error about .Tpo & .Plo being the same file when the rule that creates them creates the .Tpo then moves it to .Plo. there is no place where we ever write to .Plo otherwise. I've tried this now and in short I cannot reproduce it. I tried with Automake 1.13 now (bcs it's what available by default) and ran both on current code and an older branch, but nothing that looks like this. Many things have changed since 2014 when this was filed and I think for example that the file system was much slower back then. I suspect that the problem was that the same file was compiled twice, but since I can't reproduce it, it's impossible to determine whether it was due to problematic Makefile.am, generated Makefile, or possibly behaviour of make, so if not already closed, please close this and I'll report back if something similar returns. Cheers, Peter
