build fails due to checkout timestamps

[katef]

build fails due to checkout timestamps

[dhobsd]

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.

[line-o]

I god it to build! Thanks @dhobsd for giving the hint to touch .c and .h files. I restored src/libre/dialect/glob/parser{.c|.h} 4 times from HEAD.
Now I am curious if the binary works :)

[hvdijk]

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.

[dhobsd]

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> .

[katef]

equivalent issue for tendra: tendra/tendra#44