Git development
 help / color / mirror / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: Johannes Sixt <J.Sixt@eudaptics.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>, git@vger.kernel.org
Subject: Re: [PATCH] Avoid rebuilding everything if user changes CFLAGS on the make  command line
Date: Wed, 07 Mar 2007 10:01:14 -0800	[thread overview]
Message-ID: <7vd53lexw5.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: 45EEC122.EA43CB72@eudaptics.com

Johannes Sixt <J.Sixt@eudaptics.com> writes:

> IMHO, the value of $(CFLAGS) (which the Makefile declares as "for the
> users to override from the command line") should never take part in this
> build-flags-change-autodetection.

This on the surface looks nicer than the other Johannes's
approach, but I have reservations.  The user can always say
"make CFLAGS=-DNO_SYNLINK_HEAD=NoThanks" from the command line
to affect the behaviour, and in such a case this approach
breaks.

As long as you declare CFLAGS is there for users to override
only the way the programs are compiled (e.g. optimization) and
it is forbidden to use CFLAGS to affect the way the programs are
to behave (iow, "use of -D<FEATURE> in CFLAGS is forbidden"), it
would be Ok, but in effect it is forcing people to modify
config.mak even for "try out this configuration just this time,
one-shot" compilation, which makes me somewhat unhappy.

IGNORE_GIT_CFLAGS looks much uglier, but is much nicer from
design standpoint.  At least the user declares "I know what I am
doing, and I assume full responsibility".  That might be less
confusing in the end.

Undecided.

      reply	other threads:[~2007-03-07 18:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-06 21:50 [PATCH] Makefile: do not optimize when DEBUG=1 Johannes Schindelin
2007-03-07  9:26 ` Johannes Sixt
2007-03-07 12:37   ` Johannes Schindelin
2007-03-07 13:41     ` [PATCH] Avoid rebuilding everything if user changes CFLAGS on the make command line Johannes Sixt
2007-03-07 18:01       ` Junio C Hamano [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vd53lexw5.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=J.Sixt@eudaptics.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox