On Tue, Feb 01, 2022 at 08:09:12AM -0500, LM wrote:
Dear Laura,
> Very nice and definitely better than just using an ordinary shell script.
Calling other programs to determine and report a target's dependencies, is
convenient, efficient and not limited by any pattern description language.
This
On 22/02/05 03:23, Petros Pateros wrote:
> 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'
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
On Tue, Feb 01, 2022 at 09:29:55PM +0900, Pontus Stenetorp wrote:
> Speaking for myself, I certainly have experienced issues with
> inaccurate timestamps on NFS for compute clusters where its use is
> very common. Not saying this as a supporter of NFS and the likes, just
> as evidence that it does
*** Pedro Lucas Porcellis [2022-02-01 11:00]:
>I think for most people out there, relying on mtime is just perfectly fine.
No. mtime depends on time and filesystem implementation specifics.
There are many systems where sysadmins like to do cron-ed ntpdate,
which leads to jumping clocks. There cou
On Tue, Feb 01, 2022 at 09:29:55PM +0900, Pontus Stenetorp wrote:
> On Tue 01 Feb 2022, NRK wrote:
> > On Mon, Jan 31, 2022 at 12:10:27AM +0200, Petros Pateros wrote:
> > > However, it was pointed out to me that relying on mtime can give
> > > wrong results, for example: (a) if the clock is set bac
On Tue 01 Feb 2022, NRK wrote:
> On Mon, Jan 31, 2022 at 12:10:27AM +0200, Petros Pateros wrote:
> > However, it was pointed out to me that relying on mtime can give wrong
> > results,
> > for example:
> > (a) if the clock is set backwards or in case of insufficient granularity in
> > mtime
> > t
On Mon, Jan 31, 2022 at 12:10:27AM +0200, Petros Pateros wrote:
> However, it was pointed out to me that relying on mtime can give wrong
> results,
> for example:
> (a) if the clock is set backwards or in case of insufficient granularity in
> mtime
> then a file that gets modified might have the
On Mon, Jan 31, 2022 at 09:34:52AM -0500, LM wrote:
Dear Laura,
> This looks like a very interesting project. I've been looking for some
> alternatives to GNU make.
I hope you find something to fit your needs.
> I do use a few GNU make features that I'm not sure about porting to other
> alterna
On 22/01/31 12:10, Petros Pateros wrote:
> What would you expect from a build system? Should it trust mtime?
> Is it responsible for verifing the file's contents for actual changes?
> More generally, what are the key features that make a build system useful?
apenwarr/redo is the implementation of
>From my experience with using pure-POSIX make for many years now, I have
almost no troubles. The only recurring trouble I have is with complex
dependency chains (which I aim to keep to a minimum anyway for
simplicity) and mtime over sshfs connections. Other than that, make has
never failed me.
My
Hello, I hope you all are doing well.
Some time ago, I was using redo for building a C project, but redo, unlike make
is
non-standard, so one needed a redo implementation to build the project. At the
time, redo implementations where either written in Python,Go or had annoying
bugs
like creating
12 matches
Mail list logo
