From: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: bug-automake@gnu.org, guile-devel@gnu.org
Subject: Re: mtime of installed files
Date: Tue, 20 Jul 2010 20:14:17 +0200 [thread overview]
Message-ID: <20100720181416.GB3669@gmx.de> (raw)
In-Reply-To: <87aapmt8w1.fsf@gnu.org>
Hi Ludovic,
* Ludovic Courtès wrote on Tue, Jul 20, 2010 at 06:28:46PM CEST:
> Background: Guile 1.9/2.0 has an auto-compilation feature whereby if a
> source file has no corresponding object file in the search path, or if
> the object file is older than the source file, then the source file is
> automatically recompiled and stored in ~/.cache/guile/ccache.
I assume this part has nothing to do with Automake per se, right?
> Packages that use Guile can also choose to pre-compile all their source
> files and install both the source and object files. This saves the need
> for users to auto-compile the source. (This is what Guile does with its
> own source files.)
I assume this, too, is currently done without help of Automake, or make,
for that matter.
> For this to work, we need “make install” to guarantee the relation
> mtime(installed-object) >= mtime(installed-source), assuming we have
> mtime(builddir-object) >= mtime(srcdir-source), which will always be the
> case unless the computer’s clock is skewed.
>
> Do Automake-generated makefiles provide such a guarantee? Regardless of
> the ‘make’ implementation, OS, etc.?
This is actually a tough question; it has little to do with Automake,
much more with any or all of make, tar, cp, touch, install, libc, file
system, and the kernel.
`info Autoconf --index timestamp' leads to two nodes describing some of
the problems with time stamps. The gist is that in the worst case, any
of the above tools independently may have full or only limited timestamp
resolution (nowadays that would mostly be either nanosecond or 1 second).
Even well-run software distributions without user-compiled tools
typically can't afford to (or don't) update all of these tools at once.
Tools with limited resolution are expected to cut off fractional bits,
but there has been at least one report on autotools lists (ping me if
you need a pointer) of tools that seem to round, which violates Posix
and leads to disaster. I do not recollect how wide-spread they are.
Anyway, most of the time, these issues can be worked around, for example
by sleeping for a second before building builddir objects, or between
installing sources and installing object files, depending on whether
install -C is used or not.
Hope that helps. It might be a bit tricky or ugly to actually put this
sleep command in a normal automake Makefile.am, so if you know what
exactly you need, we can create an example.
Cheers,
Ralf
next prev parent reply other threads:[~2010-07-20 18:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-20 16:28 mtime of installed files Ludovic Courtès
2010-07-20 18:14 ` Ralf Wildenhues [this message]
2010-07-21 16:27 ` Ludovic Courtès
2010-07-21 20:53 ` Ralf Wildenhues
2010-07-27 8:18 ` Ludovic Courtès
2010-07-27 10:45 ` Ralf Wildenhues
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
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100720181416.GB3669@gmx.de \
--to=ralf.wildenhues@gmx.de \
--cc=bug-automake@gnu.org \
--cc=guile-devel@gnu.org \
--cc=ludo@gnu.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).