That would be a great extension to have for ASDF in general, but would have to be an extension, unless the maintainer is willing to put the implementation of a fast hash function in ASDF. If so, I nominate BLAKE3. It should take a few hundreds of lines of code—a relatively small amount by ASDF 3.3 standards. And if the entry function is not-inline, like all UIOP functions, it can be replaced by a very fast implementation when a suitable cryptographic library is loaded. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org He who says he will die for a cause will probably lie for it and may kill for it. — John McCarthy On Sat, Apr 17, 2021 at 7:29 PM Robert Goldman <rpgoldman@sift.info> wrote:
On 17 Apr 2021, at 17:09, Faré wrote:
One way to avoid unneeded regeneration in the future without lying about the dependency would be to modify the script to: 1. Remember in the output the hash of the input. 2. In the regeneration script, have a shortcut that leaves the output unchanged if the input matches.
That won't help if you have to deal with branches back in time, but in those cases, you can use touch to reset the .h file to an old date.
That's neat. If the hash is written to the file system (and into the Git repo), then it can be checked, and that would avoid a redo even after an initial checkout!
If you do this, Attila, please let us know -- it might be a useful capability to generalize and put in the ASDF contribs.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The greatest lies always come in a thin coating of truth.
On Sat, Apr 17, 2021 at 4:44 PM Attila Lendvai <attila.lendvai@gmail.com> wrote:
thanks for the ideas Robert!
I was wondering why it was important to avoid the build when the .h file is newer than the .spec file. This shouldn't happen very often, should it? Is it because:
the problem is much more down to earth: generating the spec file requires launching a libllvm based external tool called c2ffi. compiling and properly configuring this tool can sometimes consume a day, and the users of e.g. hu.dwim.sdl shouldn't ever need to do that. it's only needed when you want to capture newly added artifacts from the SDL.h files.
one way to avoid this could be to not communicate the dependency to ASDF, and make the .h -> .spec generation manual (this used to be the case). for some reason that feels lame, but not the end of the world either.
The .h file is getting refreshed too often by something upstream of ASDF? E.g., is make being too eager about rewriting the .h file?
the problem is not with too often, but with anything greater than zero, e.g. a git checkout.
- attila