have to say --enable-maintainer-mode
Personally I agree with you, in theory, but I think it is too big of a
change to make. As I understand it. GNU package authors have their
source repos and have never had to say --enable-maintainer-mode before
to get their Makefiles etc. rebuilt. I don't thi
Bruno Haible wrote:
Jacob Bachmeyer wrote:
under what conditions can "checking that
generated files are newer than configure" actually fail?
I mentioned two such conditions in [1]:
- Skewed clocks. (I see this regularly on VMs that have 1 or 2 hours
of skew.)
- If the configure
Zack Weinberg wrote:
On Tue, Jun 18, 2024, at 12:02 AM, Jacob Bachmeyer wrote:
[...]
Wait... all of configure's non-system dependencies are in the release
tarball and presumably (if "make dist" worked correctly) backdated
older than configure when the tarball is unpacked.
In my experie
On Tue, Jun 18, 2024, at 10:19 AM, Bruno Haible wrote:
> Zack Weinberg wrote:
>> Literally as I type this I am
>> watching gettext 0.22 run its ridiculous number of configure scripts a
>> second time from inside `make`.
>
> You can run into such problems:
> - if you take a tarball of a git reposi
Zack Weinberg wrote:
> Literally as I type this I am
> watching gettext 0.22 run its ridiculous number of configure scripts a
> second time from inside `make`.
I'm glad that you didn't write "its ridiculously large configure scripts" :-)
Jokes aside, it's highly unusual that 'configure' runs twic
On Tue, Jun 18, 2024, at 12:02 AM, Jacob Bachmeyer wrote:
> Zack Weinberg wrote:
>> On Mon, Jun 17, 2024, at 10:30 PM, Jacob Bachmeyer wrote:
>>
>> I regret to say, yes, there are. For example, this can happen with
>> NFS if there are multiple clients updating the same files and they
>> don't all a
Jacob Bachmeyer wrote:
> under what conditions can "checking that
> generated files are newer than configure" actually fail?
I mentioned two such conditions in [1]:
- Skewed clocks. (I see this regularly on VMs that have 1 or 2 hours
of skew.)
- If the configure file was created less than
Zack Weinberg wrote:
On Mon, Jun 17, 2024, at 10:30 PM, Jacob Bachmeyer wrote:
...
Don't have enough brain right now to comment on any of the rest of your
suggestions, but:
once conftest.file is newer than configure, surely
config.status, which is produced after all tests are run, /must/ a
On Mon, Jun 17, 2024, at 10:30 PM, Jacob Bachmeyer wrote:
...
Don't have enough brain right now to comment on any of the rest of your
suggestions, but:
>once conftest.file is newer than configure, surely
> config.status, which is produced after all tests are run, /must/ also be
> newer than co
Nick Bowler wrote:
On 2024-06-16 21:35, Jacob Bachmeyer wrote:
I think we might best be able to avoid this by using AC_CONFIG_COMMANDS_POST
to touch config.status if neccessary, instead of trying to decide
whether to sleep before writing config.status.
If the problem is simply that we
Nick Bowler wrote:
> while ${MAKE-make} -f conftest.mk >/dev/null 2>&1
> do
> touch config.status
> done])
I would use 'echo >> config.status' instead of 'touch config.status'.
Rationale: When the user is working in an NFS file system mount,
and there is a clock skew between the current
Karl Berry wrote:
>This patch is conservative; IMO safe for a 1.17 release.
>
> I like the idea of a conservative patch, for sure. I see that what
> you're doing here is simply omitting the 1 second trial for the sake of
> saving that time, in exchange for accepting a 2s delay in the Automake
Let's look at the history.
Thanks very much for all that research and explanations, Bruno.
Likewise, Jacob.
https://lists.gnu.org/archive/html/bug-automake/2010-10/msg0.html
Aha, the explanation for some of the $sleep commands scattered
throughout the Automake tests! I had no idea. I
Nick>
AC_CONFIG_COMMANDS_POST([cat >conftest.mk <<'EOF'
configure: config.status
false
EOF
while ${MAKE-make} -f conftest.mk >/dev/null 2>&1
do
touch config.status
done])
One missing element is that there is no limit, which would be a
On 2024-06-16 21:35, Jacob Bachmeyer wrote:
> I think we might best be able to avoid this by using AC_CONFIG_COMMANDS_POST
> to touch config.status if neccessary, instead of trying to decide
> whether to sleep before writing config.status.
If the problem is simply that we want to avoid the situati
Karl Berry wrote:
Find here attached a revised proposed patch.
Ok on the reorg, but sorry, I remain confused. This whole thing started
with Mike Vapier's change in Feb 2022 (commit 720a11531):
https://lists.gnu.org/archive/html/automake-commit/2022-02/msg9.html
As I read it now, his goa
Two days ago, I wrote:
> Find here attached a revised proposed patch.
But I had missed the parallel 'sleep $am_cv_filesystem_timestamp_resolution'.
Sorry, I have to withdraw that patch as well.
Now, with the big picture that I gained by replying to Karl's
questions, here are two alternative, prop
Hi Karl,
> I understand that equal timestamps are considered up to date
Yes, except for old HP-UX 'make', which no one uses any more, all 'make'
programs consider equal timestamps as "up-to-date".
> Ok, but
> then why is configure generating config.status/etc. such a special case
> that it requi
Find here attached a revised proposed patch.
Ok on the reorg, but sorry, I remain confused. This whole thing started
with Mike Vapier's change in Feb 2022 (commit 720a11531):
https://lists.gnu.org/archive/html/automake-commit/2022-02/msg9.html
As I read it now, his goal was to speed up ot
Hi Karl,
Karl Berry wrote:
> Sorry, but I don't really understand your patch. With it, it would seem
> that _AM_FILESYSTEM_TIMESTAMP_RESOLUTION is only called if the build
> environment is not "sane", i.e., a created file is not newer than
> configure. Is that right?
Yes, that's the intent — for
Sorry, but I don't really understand your patch. With it, it would seem
that _AM_FILESYSTEM_TIMESTAMP_RESOLUTION is only called if the build
environment is not "sane", i.e., a created file is not newer than
configure. Is that right? (That embedded shell construct is hard to grok.)
is in _AM_FI
Nick Bowler wrote:
> Maybe this is a silly question, but, is there a reason why this test
> needs to be performed in every single package that uses Automake?
Excellent point. The best optimization of a certain code is the one
that avoids executing the code entirely.
With Karl's newest patch, it's
Hi,
On 6/13/24 10:44, Jacob Bachmeyer wrote:
Second, because timestamp resolution is actually per-volume,
which in the POSIX model, means it varies by directory. You can even
have a modern filesystem (with nanosecond granularity) mounted on a
directory in a FAT filesystem (with two second gr
dherr...@tentpost.com wrote:
At some point, it becomes unreasonable to burden common platforms with
delays that only support relatively obscure and obsolete platforms.
Configure scripts already have a bad reputation for wasting time.
Even if they are faster than editing a custom makefile, the
Does BSD ls(1) support "--time=ctime --time-style=full-iso"?
BSD ls does not support any --longopts. Looking at the man page,
I don't see "millisecond" or "subsecond" etc. mentioned, though I could
easily be missing it. E.g.,
https://man.freebsd.org/cgi/man.cgi?ls
Even if there is such an
It should save 6 seconds. Because it goes like this:
- Test whether 0.01 sec works.
- Test whether 0.1 sec works.
- If not, set the variable to 2, because that's the worst case and it
*must* work.
At which places will then a 'sleep 2' be done where (if not VFAT) a
> Any other ideas?
A horrible one:
:)
split the test so it can be performed in parallel with
others -- upper half starts the sleep in the background, lower half
waits for it to complete.
No thanks. I can't even begin to imagine the portability and edge case
problems that w
On Tue, Jun 11, 2024, at 7:00 PM, Karl Berry wrote:
> Maybe this is a silly question, but, is there a reason why this test
> needs to be performed in every single package that uses Automake?
>
> I was under the impression that the purpose of this test was
> merely to speed up running Automa
Hi,
On 6/12/24 08:00, Karl Berry wrote:
Any other ideas?
A horrible one: split the test so it can be performed in parallel with
others -- upper half starts the sleep in the background, lower half
waits for it to complete.
Simon
At some point, it becomes unreasonable to burden common platforms with
delays that only support relatively obscure and obsolete platforms.
Configure scripts already have a bad reputation for wasting time. Even
if they are faster than editing a custom makefile, they are idle instead
of active
Karl Berry wrote:
bh> Seen e.g. on NetBSD 10.0.
Which doesn't support subsecond mtimes?
jb> Maybe the best answer is to test for subsecond timestamp
granularity first, and then only do the slow test to distinguish
between 1-second and 2-second granularity if the subsecond
gr
Karl Berry wrote:
> The simple change is to omit the make test if we are at resolution 1.
> That will save 4 seconds.
It should save 6 seconds. Because it goes like this:
- Test whether 0.01 sec works.
- Test whether 0.1 sec works.
- If not, set the variable to 2, because that's the worst ca
Maybe this is a silly question, but, is there a reason why this test
needs to be performed in every single package that uses Automake?
I was under the impression that the purpose of this test was merely
to speed up running Automake's own test suite.
There are other packages that h
bh> Seen e.g. on NetBSD 10.0.
Which doesn't support subsecond mtimes?
jb> Maybe the best answer is to test for subsecond timestamp
granularity first, and then only do the slow test to distinguish
between 1-second and 2-second granularity if the subsecond
granularity test gives
Date: Sat, 08 Jun 2024 00:27:39 +0200
From: Bruno Haible
To:
Subject: 1.16.90 regression: configure now takes 7 seconds to start
[I'm writing to automake@gnu.org because bug-autom...@gnu.org
appears to be equivalent to /dev/null: [...]
It seems this has been fixed, what
On 2024-06-07 19:26, Jacob Bachmeyer wrote:
> Bruno Haible wrote:
>> [I'm writing to automake@gnu.org because bug-autom...@gnu.org appears
>> to be equivalent to /dev/null: no echo in
>> https://lists.gnu.org/archive/html/bug-automake/2024-06/threads.html
>> nor in https://debbugs.gnu.org/cgi/pkgre
Bruno Haible wrote:
Hi Jacob,
AFAIU, the 4x sleep 0.1 are to determine whether
am_cv_filesystem_timestamp_resolution should be set to 0.1 or to 1.
OK, so be it.
But the 6x sleep 1 are to determine whether
am_cv_filesystem_timestamp_resolution should be set to 1 or 2.
2 is known to be the ca
Hi,
On 6/8/24 08:50, Bruno Haible wrote:
You can't achieve portability by using a highly unportable program
like 'stat'. That's why my patch only uses 'df' and 'mount'.
You can test if it's available, and fall back if not.
I don't care much about the 0.4 seconds spent on determining sub-sec
Hi Jacob,
> > AFAIU, the 4x sleep 0.1 are to determine whether
> > am_cv_filesystem_timestamp_resolution should be set to 0.1 or to 1.
> > OK, so be it.
> >
> > But the 6x sleep 1 are to determine whether
> > am_cv_filesystem_timestamp_resolution should be set to 1 or 2.
> > 2 is known to be the c
Bruno Haible wrote:
[I'm writing to automake@gnu.org because bug-autom...@gnu.org
appears to be equivalent to /dev/null: no echo in
https://lists.gnu.org/archive/html/bug-automake/2024-06/threads.html
nor in https://debbugs.gnu.org/cgi/pkgreport.cgi?package=automake,
even after several hours.]
I
40 matches
Mail list logo
