[PATCH] Makefile: add CC to TRACK_CFLAGS

Change the git make process so that everything's rebuilt if the CC is
changed. Before we wouldn't rebuilt if e.g. the CC variable was
changed from gcc to clang.

Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---
 Makefile |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index c27e8bc..c46893a 100644
--- a/Makefile
+++ b/Makefile

@@ -1969,7 +1969,7 @@ cscope:
 	$(FIND) . -name '*.[hcS]' -print | xargs cscope -b
 
 ### Detect prefix changes
-TRACK_CFLAGS = $(subst ','\'',$(ALL_CFLAGS)):\
+TRACK_CFLAGS = $(CC):$(subst ','\'',$(ALL_CFLAGS)):\
              $(bindir_SQ):$(gitexecdir_SQ):$(template_dir_SQ):$(prefix_SQ)
 
 GIT-CFLAGS: FORCE

-- 
1.7.2.3.313.gcd15

On Sun, Sep 12, 2010 at 22:37, Ævar Arnfjörð Bjarmason [off-list ref] wrote:

Change the git make process so that everything's rebuilt if the CC is
changed. Before we wouldn't rebuilt if e.g. the CC variable was
changed from gcc to clang.

Is there a reason for why this didn't get picked up other than falling
through the cracks?

Ævar Arnfjörð Bjarmason [off-list ref] writes:

Is there a reason for why this didn't get picked up other than falling
through the cracks?

Simply because I wasn't actively collecting new topics during feature
freeze, especially for small stuff that I knew that resending after
release would be trivial and more efficient use of my time than queuing it
in 'pu' and having to look at it every time I do another push-out in order
to decide when to merge it to 'next'.

After a feature release like 1.7.3, my preference is to do these in this
order:

 (0) take a deep breath and have bit of break ;-);

 (1) rewind 'next' to match 1.7.3 with selected topics that has been
     cooking there, rename 'maint' to 'maint-1.7.2', and start 'maint' at
     1.7.3;

 (2) have a quiet period for at least a few days, not touching 'master' at
     all, to make sure things are stable, giving users time to give us
     feedback, and giving us time to assess potential damages caused by
     unanticipated regressions;

 (3) collect brown-paper-bag regression fixes, if necessary, during the
     period overlapping with (2), queuing them to 'next';

 (4) have (3) graduate and issue 1.7.3.1 out of 'maint';

And after all that, open the 1.7.4 cycle, queuing new topics.  That would
also be a good time to backmerge the safe fixes (but not new features)
that went to 1.7.3 to maint-1.7.2, and cut 1.7.2.4, so that it will be a
reasonably solid base to apply later security fixes if necessary.

On Mon, Sep 20, 2010 at 01:46, Junio C Hamano [off-list ref] wrote:

Ævar Arnfjörð Bjarmason [off-list ref] writes:

quoted

Is there a reason for why this didn't get picked up other than falling
through the cracks?

Simply because I wasn't actively collecting new topics during feature
freeze, especially for small stuff that I knew that resending after
release would be trivial and more efficient use of my time than queuing it
in 'pu' and having to look at it every time I do another push-out in order
to decide when to merge it to 'next'.

Rigth, I have no problem doing $whatever to get patches in, but the
problem I often have is that I don't know what state things are in,
and what I'm supposed to do at any given time.

E.g. in this case I submitted the "send-email: use catfile() to
concatenate files" patch 2 days after this one, that one got into the
next "What's cooking in git.git" post.

Since both were trivial fixes and there was no comment on this one I
was inclined to think that it just fell through.

Should I generally re-send patches that I've sent, haven't had
comments, and haven't appeared in subsequent "What's cooking in
git.git" posts (given that some reasonable amount of time has passed
since the original send) ?

Then there's stuff like my "git-am: Ignore whitespace before patches"
which had some comments, but which *I* still think is OK as-is. Should
I just keep pushing stuff like that until someone tells me to stop?

Thanks, from a list member somewhat confused about the patch queue :)