All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>
To: Russell King <rmk@arm.linux.org.uk>
Cc: Keith Owens <kaos@ocs.com.au>, <linux-kernel@vger.kernel.org>
Subject: Re: [patch] 2.5.25 net/core/Makefile
Date: Mon, 22 Jul 2002 09:29:08 -0500 (CDT)	[thread overview]
Message-ID: <Pine.LNX.4.44.0207220909530.28150-100000@chaos.physics.uiowa.edu> (raw)
In-Reply-To: <20020722090704.A2052@flint.arm.linux.org.uk>

On Mon, 22 Jul 2002, Russell King wrote:

> On Mon, Jul 22, 2002 at 11:08:41AM +1000, Keith Owens wrote:
> > It is required if you ever want autoconfigure to work, that
> > distinguishes between "" (undefined) and "n" (explicitly turned off).
> > Forward planning.
> 
> Wouldn't it be better to fix the existing config tools to output "=n"
> instead of "# CONFIG_foo is not set" ?  IIRC they do the translation
> back and forth internally anyway, so it should be just a matter of
> removing some code from the tools.

The point is, what would such a change buy us? It needs going through all 
Makefiles, updating 

	ifdef CONFIG_XYZ

to

	ifneq ($(CONFIG_XYZ),n)


(or ifeq ($(CONFIG_XYZ),y) when we now it's a bool)

Actually, now this won't handle the CONFIG_XYZ unset case, which may well 
happen since a part of Config.in which would set or unset the symbols 
may not even get sourced.

So we really have to use

	ifneq ($(subst n,,$(CONFIG_XYZ),)

instead. That's ugly and doesn't have any advantage over what we have 
now, AFAICS.

Inside the Config.in scripts it's annoying that you have to check against
"n" || "" (or ! ("y" || "m") ). The reasons for that lie, for all I can
tell, in the use of sh/bash for the original Configure script. In any
case, if this behavior is considered too annoying, it should be fixed in
the config system, but there's no reason to change the Makefile/.config 
syntax, too.

(I think it may actually possible to fix it even within Configure, by just
always using <undef> instead of "n" - Configure needs to keep track of all
the encountered symbols anyway - but I didn't try. This would also
decrease the confusion, as then both the Makefiles and Config.in would
both use "y","m",<undef>.

W.r.t autoconfigure, I think that can easily be achieved using/extending 
the existing .config format.

Just have

	# CONFIG_FOO is not set
vs
	# CONFIG_FOO=n

or even

	<CONFIG_FOO not mentioned in .config>

vs the current

	# CONFIG_FOO is not set

Should be nicely compatible with all existing tools.

--Kai



  parent reply	other threads:[~2002-07-22 14:26 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-06  8:30 [patch] 2.5.25 net/core/Makefile Keith Owens
2002-07-09  0:11 ` Dave Jones
2002-07-09  0:30   ` Keith Owens
2002-07-09  0:36     ` Dave Jones
2002-07-09  2:13       ` Keith Owens
2002-07-09  2:24         ` Arnaldo Carvalho de Melo
2002-07-21 23:56 ` Kai Germaschewski
2002-07-22  1:08   ` Keith Owens
2002-07-22  8:07     ` Russell King
2002-07-22  8:37       ` Roman Zippel
2002-07-22  8:51         ` Andreas Schwab
2002-07-22  8:55           ` Russell King
2002-07-22  9:23             ` Roman Zippel
2002-07-22 14:29       ` Kai Germaschewski [this message]
2002-07-11  3:53 Thunder from the hill

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=Pine.LNX.4.44.0207220909530.28150-100000@chaos.physics.uiowa.edu \
    --to=kai@tp1.ruhr-uni-bochum.de \
    --cc=kaos@ocs.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rmk@arm.linux.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.