Achim Gratz writes:
> François Pinard writes:
>> Any Makefile which lists dependencies while expecting them to be
>> satisfied sequentially, one after another, is broken. Make does not
>> (theoretically) guarantee the order, while in practice, all "make"
>> programs I know satisfy dependencies
François Pinard writes:
> Any Makefile which lists dependencies while expecting them to be
> satisfied sequentially, one after another, is broken. Make does not
> (theoretically) guarantee the order, while in practice, all "make"
> programs I know satisfy dependencies from left to right.
Well, if
François Pinard writes:
> Any Makefile which lists dependencies while expecting them to be
> satisfied sequentially, one after another, is broken. Make does not
> (theoretically) guarantee the order, while in practice, all "make"
> programs I know satisfy dependencies from left to right.
I can t
Achim Gratz writes:
> .PHONY: testclean # in case you'll ever have a file named "testclean"
> testclean: test clean
> In general all such targets that are simple combinations of existing
> teargets can be added that way.
Allow me a pedantic nit-pick, yet nothing so important in practice
n
Achim Gratz writes:
> Bastien writes:
>> Yes, that's the mistake I often did. Especially because make test
>> compiles the file and do not deleted the compiled files.
>>
>> Maybe we can have make testclean = make test && make clean
>>
>> Achim, would that be useful?
>
> We already have "make tes
Hi Achim,
Achim Gratz writes:
> We already have "make test-dirty" for testing without doing a compile.
> However, if you'd rather have that target, you can easily add it to
> local.mk:
>
> .PHONY: testclean # in case you'll ever have a file named "testclean"
> testclean: test clean
>
> In g
Bastien writes:
> Yes, that's the mistake I often did. Especially because make test
> compiles the file and do not deleted the compiled files.
>
> Maybe we can have make testclean = make test && make clean
>
> Achim, would that be useful?
We already have "make test-dirty" for testing without doin
(Updating the subject.)
Eric Abrahamsen writes:
> Related to this -- how do you folks handle multiple local git branches?
> Do you always run uncompiled, and follow every git checkout with
> org-reload? I've caught myself several times recently doing git
> checkouts and reloading, but of course
