only perfom when the output is missing

[Robert Goldman]

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