Thank you all for your answers.
On Mon, Jan 31, 2022 at 06:38:01PM +0100, Страхиња Радић wrote:
> apenwarr/redo is the implementation of djb redo I settled on for my programs.
> It
> has the most features among the current implementations.
I'm glad to hear that. But it doesn't implement the less-features feature (that
comes
along with the only-the-features-necessary-for-the-do-one-job-well-plan) that I
was looking for ;-).
> For redistribution, it
> has a shell script named "do", so even if users don't have full apenwarr/redo
> installed on their system, they can execute
>
> $ ./do -c
>
> to build my programs, or
>
> # ./do -c install
>
> to install them.
I have actually overseen this, thank you for mentioning.
It seems that we need to solve the problem of characterising
a dependency as out-of-date
- when mtime is reliable
- when mtime is not.
It also seems to me that mtime is unreliable when a component of the system
"breaks"
mtime (NFS, etc.). So, since the degree of mtime reliability is known
beforehand,
I'd prefer having two separate build-system implementations, one that always
relies
on mtime and one that checks the file's contents.
One would use the first for the majority of practical cases, and the second for
the rest cases.
This would solve the simple ones simply (with simplicity) and efficiently and
the rest with the necessary complexity.
Particularly with redo, one is able use both with the same interface (without
any
need for adapting the build scripts).
If one deems mtime always unreliable, then they can only use the second.
Personally, I think the first case has me covered.
For those interested, baredo only hanldes the simple case, but can be trivially
extented to handle the other cases as well (trivially when one has the code for
the hashing or whatever). Feel free to contact me if I you need help in regards
to this.
Cheers!
