Hi all,
There's been a lot of good discussion on this. Extensibility, avoiding
unnecessary rebuilds, preventing missed rebuilds, ensuring checks don't
get re-run every time, etc.
Those are hard issues to get right.
Persistent storage of the non-timestamp checks is another issue that has
b
On 04/11/2015 08:38 AM, Enrico Weigelt, metux IT consult wrote:
On 07.04.2015 00:17, Eric Melski wrote:
Hi,
This problem is relatively common when using an SCM system that
preserves *checkin* time on files rather than *checkout* time.
I'd consider that a misbehavious of the SCM (IMHO, that's
On 11 April 2015 at 16:38, Enrico Weigelt, metux IT consult <
enrico.weig...@gr13.net> wrote:
> On 07.04.2015 00:17, Eric Melski wrote:
>
>
> > ClearCase
> > does this in various configurations, and Perforce will if your client
> > spec has "modtime" set. I'm sure other SCM systems can be setup t
On 07.04.2015 00:17, Eric Melski wrote:
Hi,
> This problem is relatively common when using an SCM system that
> preserves *checkin* time on files rather than *checkout* time.
I'd consider that a misbehavious of the SCM (IMHO, that's the reason
why Git does not track the mtime). From the filesys
It should be noted that there are published methods for hash reliance
within the current syntax, e.g.
http://www.cmcrossroads.com/article/rebuilding-when-files-checksum-changes.
I haven’t ever tried this, in fact I haven’t even read the article in
detail, but you might want to play with it before
On 04/04/2015 11:38 AM, Tim Murphy wrote:
>My thinking is that the timestamp is in fact an overly conservative
> test. We never have the case that the timestamp indicates something
> *has not* been changed when in fact it has (i.e. we always build if
> something has cha
>
> >My thinking is that the timestamp is in fact an overly conservative
> > test. We never have the case that the timestamp indicates something
> > *has not* been changed when in fact it has (i.e. we always build if
> > something has changed),
>
> That's interesting, because in my exper
On Thu, 2015-04-02 at 13:20 +0200, Glen Stark wrote:
> You asked "what if people want to define their own "out-of-date-ness"
> test?". I found that a really exciting idea. As I thought about
> this, I realized I what I really want is not to replace Make's current
> behavior, but to add an
nces+martin.dorey=hds@gnu.org
[mailto:bug-make-bounces+martin.dorey=hds@gnu.org] On Behalf Of Edward
Welbourne
Sent: Thursday, April 02, 2015 10:49
To: m...@glenstark.net
Cc: bug-make@gnu.org
Subject: Re: Using hash instead of timestamps to check for changes.
> After reading over your
> After reading over your mail a couple of times, I realized that I hadn't
> thought things through very well. In fact, rather than saying "hash
> instead of time", I should have said "optional additional hash check
> when timestamp has changed".
Even so, I'm unclear about why "hash" is the thing
Hello Paul
Sorry to take so long to reply. I wanted to think your input over, and
I've had a pretty heavy load lately.
Signing over the copyright, and any other legal steps won't be a
problem. My company has no rights to work I do in my own time. I'm
mainly worried about the technical issues,
On Fri, 2015-03-27 at 11:45 -0400, Paul Smith wrote:
> * Do we really need to hash the file? Maybe simply expanding the
> current checking is sufficient. For example, if in addition to
> mod time we also considered the size of the file (and maybe
> other things maint
On Fri, 2015-03-27 at 14:42 +0100, Glen Stark wrote:
> Is this planned? Has the idea already been rejected, and if so could
> you point me to the discussion so I can inform myself?
There is no formal planning around it right now, and it's not at the top
of my TODO list for GNU make.
> If it is p
Hi.
Notice that I am not a GNU Make developer.
The feature which checks updates depend on file content differ of each file is
not implemented on GNU Make currently.
(I think it won't be implemented because timestamp-based update checking is
normal behavior of Make.)
If you want to check update
14 matches
Mail list logo
