Makefile: touch lib directory after installing dependencies

[waj]

This is to avoid the situation where, if the shard.lock has a mtime more recent than lib directory, the dependencies are installed every time. Is there a better solution for this?

[j8r]

Why the lib directory mtime matters? It shouldn't, shards should check the version of each library inside this directory each time shards install is run.

[waj]

Of course it does. But I don’t want to see the action being executed every time.

[straight-shoota]

@j8r This is not about shards' behaviour when installing dependencie. It just fixes the Makefile recipe for lib in this repo.

[waj]

Oh... sorry, the title was misleading

[j8r]

@straight-shoota yeah, I don't understand why shards take into account the mtime of lib and shard.lock?

[jhass]

@straight-shoota yeah, I don't understand why shards take into account the mtime of lib and shard.lock?

It does not, make does.

[jhass]

I wouldn't be surprised if this is the initial reason for touch to exist :D

[straight-shoota]

@j8r When you run a make tasks like bin/shards that depends on lib, make checks the mtime of the target (i.e. the lib folder). If that is older than its dependencies (shard.lock), it executes the recipe for lib. That can be avoided by updating mtime every time the recipe runs. Running touch on the target is a typical solution in Makefiles when the recipe itself doesn't update the mtime.

[repomaa]

maybe related to #381 ?

[straight-shoota]

Yeah #381 seems like a good alternative. However, it doesn't fix the problem: If shard.yml was updated with no changes relevant to dependency resolution, then shard.lock will retain an older mtime and the recipe for shard.lock will run shards update every time.

But this could maybe be solved if #381 touches shard.lock even when it didn't change but is older than shard.yml.

[straight-shoota]

Even shards update doesn't touch lib. Feels like it clearly should.
I'm not entirely sure about shards install with no changes. But update should definitely.