On Tue, 11 Jun 2019 14:25:10 -0800, Britton Kerin
wrote:
> > I think .COMMANDCHANGE is not complex.
> > Since it caches the expanded command, at worst it will re-run a script
> > when before it would not have done so.
> > So it's relatively low risk; at worst, it'll run a command more often than
> I think .COMMANDCHANGE is not complex.
> Since it caches the expanded command, at worst it will re-run a script
> when before it would not have done so.
> So it's relatively low risk; at worst, it'll run a command more often than
> before.
> It won't rerun if only an environment variable changes
> On Mon, 2019-06-10 at 13:14 -0400, David A. Wheeler wrote:
> > Idea: Add .COMMANDCHANGE and .CACHE
On Tue, 11 Jun 2019 11:06:51 -0400, Paul Smith wrote:
> Unlike some of the other ideas I think this one needs a lot of thought
> and consideration. To me it seems the most compl
On Mon, 2019-06-10 at 13:14 -0400, David A. Wheeler wrote:
> Idea: Add .COMMANDCHANGE and .CACHE
Unlike some of the other ideas I think this one needs a lot of thought
and consideration. To me it seems the most complex and the most likely
to have unintended side-effects or for the implementat
Edward Welbourne writes:
> On Mon, Jun 10, 2019 at 5:14 PM David A. Wheeler
> wrote:
> >>> Using a lot of some_fragment.mk files gets you *closer*, but it's not
> >>> the same thing. My proposed .COMMANDCHANGE depends on
> >>> the *expanded* set of commands, not the original commands.
> >>
On Mon, Jun 10, 2019 at 5:14 PM David A. Wheeler wrote:
>>> Using a lot of some_fragment.mk files gets you *closer*, but it's not
>>> the same thing. My proposed .COMMANDCHANGE depends on
>>> the *expanded* set of commands, not the original commands.
>>> That way, if you change a value (say CCFLA
On Mon, Jun 10, 2019 at 5:14 PM David A. Wheeler wrote:
> > Using a lot of some_fragment.mk files gets you *closer*, but it's not
> > the same thing. My proposed .COMMANDCHANGE depends on
> > the *expanded* set of commands, not the original commands.
> > That way, if you change a value (say CCFLA
On Mon, Jun 10, 2019 at 5:14 PM David A. Wheeler wrote:
>
> On Mon, 10 Jun 2019 15:40:53 -0800, Britton Kerin
> wrote:
> > No, just the rules that :Makefile, which you can easily tune if it matters.
> > Heck, you can include some_fragment.mk that has the recipes that
> > are a concern and depend
On further reflection I noticed a bug in my .CACHE proposal.
Below is a discussion of the bug, and my proposed solution to it.
The proposed solution turns out to be a minor change,
but it might not be obvious why it needed changing.
So I'm explaining that in detail below.
TL; DR version: If .CACH
On Mon, 10 Jun 2019 15:40:53 -0800, Britton Kerin
wrote:
> No, just the rules that :Makefile, which you can easily tune if it matters.
> Heck, you can include some_fragment.mk that has the recipes that
> are a concern and depend on that if you really need that granularity,
> and then the dependen
On Mon, Jun 10, 2019 at 2:18 PM David A. Wheeler wrote:
>
> On Mon, 10 Jun 2019 12:10:26 -0800, Britton Kerin
> wrote:
> > The trickery required is not too fancy:
> >
> > foo.o: foo.c Makefile
> > ...
> > or
> >
> > foo.o: foo.c $(PARANOID_REBUILD)
> > ...
> >
On Mon, 10 Jun 2019 12:10:26 -0800, Britton Kerin
wrote:
> The trickery required is not too fancy:
>
> foo.o: foo.c Makefile
> ...
> or
>
> foo.o: foo.c $(PARANOID_REBUILD)
> ...
>
> Then use when desired:
> (export PARANOID_REBUILD=Makefile && Make)
N
On Mon, Jun 10, 2019 at 9:20 AM David A. Wheeler wrote:
>
> Idea: Add .COMMANDCHANGE and .CACHE
>
> Problem:
>
> Paul Smith noted on Sun, 09 Jun 2019 22:11:32 -0400:
> > Most of the requests I see these days that would require a "last state
> > database"
Idea: Add .COMMANDCHANGE and .CACHE
Problem:
Paul Smith noted on Sun, 09 Jun 2019 22:11:32 -0400:
> Most of the requests I see these days that would require a "last state
> database" wouldn't be helped by md5 checks: mainly they're asking for
> things like rebuildi
14 matches
Mail list logo
