New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
build fails due to checkout timestamps #273
Comments
sid is part of tendra, but you shouldn't need this to build from a clean checkout. You might try touching the .c and .h output files (they're intended to be checked in) to get further now. If that still fails, it's possible recent libre changes forgot to regenerate these files. Edit: Either way, should look into this. Will try to repro later this morning if someone else doesn't. |
I god it to build! Thanks @dhobsd for giving the hint to touch .c and .h files. I restored |
This is a common problem with Git, especially on systems where both the file system and make support sub-second resolution for file modification time. When cloning a repository, Git will not do anything special with the file mtimes, they correspond to the time the file was written, and files are not guaranteed to be written in any particular order. Generated files may be written before their sources, triggering spurious regenerations if make detects this as an outdated generated file. There are generally two ways around this in a Git repo:
Alternatively, this can be done by not cloning from Git, but instead using Github's functionality to download a tarball or zip file, and extracting that. This works because the tarball/zip file will mark every file with the same modification time. |
I wonder if we can indirect in kmkf through a dependency file that contains
the sha of input(s) and output(s) such that we only regenerate if the tied
shas differ, regardless of mtime.
…On Wed, Oct 14, 2020 at 09:42 Harald van Dijk ***@***.***> wrote:
This is a common problem with Git, especially on systems where both the
file system and make support sub-second resolution for file modification
time. When cloning a repository, Git will not do anything special with the
file mtimes, they correspond to the time the file was written, and files
are not guaranteed to be written in any particular order. Generated files
may be written before their sources, triggering spurious regenerations if
make detects this as an outdated generated file.
There are generally two ways around this in a Git repo:
- Provide a way to set all repository file modification times to the
same value. On a git checkout, this can be done with git ls-files |
xargs touch -r <file>, where <file> is any file you like, to set all
files to the same mtime. This is not generally safe, as file names may
contain characters that need special handling, but is safe for libfsm, as
it does not contain any such file. A safer alternative is git ls-files
-z | xargs -0 touch -r <file> --, but xargs -0 is not universally
supported.
- Provide a way to disable the make rules for regenerating files. This
is something seen in autoconf/automake, where you can specify
--enable-maintainer-mode to enable such rules, or --disable-maintainer-mode
to disable them, see https://autotools.io/automake/maintainer.html. In
make, this could be achieved by adding logic to respond to a
MAINTAINER_MODE=0 variable. Any other name would work equally well.
Alternatively, this can be done by not cloning from Git, but instead using
Github's functionality to download a tarball or zip file, and extracting
that. This works because the tarball/zip file will mark every file with the
same modification time.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#273 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABJFR7EQGTUVWQRNNR5E2TSKXIGJANCNFSM4SQUPYPQ>
.
|
equivalent issue for tendra: tendra/tendra#44 |
I tried to
bmake -r install
,PREFIX=/tmp/x bmake -r install
andCC=clang PREFIX=$HOME bmake -r install
they all die with
But I could not find a hint were to get
sid
on OSX. I hope, it is totally obvious how to fix this.The text was updated successfully, but these errors were encountered: