[PATCH] kconfig: menuconfig and config uses $objtree

[PATCH] kconfig: menuconfig and config uses $objtree

[Sam Ravnborg]

In order to prepare for separate obj and src trees make use of $objtree
within scripts/Menuconfig and scripts/Configure.
All temporary and all result files are located in directory pointed at
by $objtree.

This functionality is foreseen useful for both current kbuild and kbuild-2.5

	Sam

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.611   -> 1.612  
#	  scripts/Menuconfig	1.6     -> 1.7    
#	   scripts/Configure	1.6     -> 1.7    
#	scripts/lxdialog/menubox.c	1.2     -> 1.3    
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 02/06/27	sam@mars.ravnborg.org	1.612
# To prepare for separate SRC and OBJ trees scripts/Configure and 
# scripts/Menuconfig now use $objtree for all temporary and result files.
# .config will from now on be placed in $objtree/.config which for the moment
# is equal to $TOPDIR.
# --------------------------------------------
#
diff -Nru a/scripts/Configure b/scripts/Configure
--- a/scripts/Configure	Fri Jun 28 00:09:08 2002
+++ b/scripts/Configure	Fri Jun 28 00:09:08 2002
@@ -125,7 +125,7 @@
    #first escape regexp special characters in the argument:
    var=$(echo "$1"|sed 's/[][\/.^$*]/\\&/g')
    #now pick out the right help text:
-   text=$(cat /dev/null $(find . -name Config.help) |
+   text=$(cat /dev/null $(find $srctree -name Config.help) |
 	sed -n "/^$var[ 	]*\$/,\${
 			/^$var[ 	]*\$/c\\
 ${var}:\\
@@ -600,9 +600,9 @@
 	done
 }
 
-CONFIG=.tmpconfig
-CONFIG_H=.tmpconfig.h
-FORCE_DEFAULT=.force_default
+CONFIG=$objtree/.tmpconfig
+CONFIG_H=$objtree/.tmpconfig.h
+FORCE_DEFAULT=$objtree/.force_default
 trap "rm -f $CONFIG $CONFIG_H ; exit 1" 1 2
 
 #
@@ -638,7 +638,7 @@
 	CONFIG_IN=$1
 fi
 
-for DEFAULTS in .config /lib/modules/`uname -r`/.config /etc/kernel-config /boot/config-`uname -r` arch/$ARCH/defconfig
+for DEFAULTS in $objtree/.config /lib/modules/`uname -r`/.config /etc/kernel-config /boot/config-`uname -r` arch/$ARCH/defconfig
 do
   [ -r $DEFAULTS ] && break
 done
@@ -649,9 +649,9 @@
     echo "# Using defaults found in" $DEFAULTS
     echo "#"
     . $DEFAULTS
-    sed -e 's/# \(CONFIG_[^ ]*\) is not.*/\1=n/' <$DEFAULTS >.config-is-not.$$
-    . .config-is-not.$$
-    rm .config-is-not.$$
+    sed -e 's/# \(CONFIG_[^ ]*\) is not.*/\1=n/' <$DEFAULTS >$objtree/.config-is-not.$$
+    . $objtree/.config-is-not.$$
+    rm $objtree/.config-is-not.$$
   else
     echo "#"
     echo "# No defaults found"
@@ -666,9 +666,9 @@
 s/# \(CONFIG_[^ ]*\) is not.*/\1=n/;
 s/# range \(CONFIG_[^ ]*\) \([^ ][^ ]*\) \([^ ][^ ]*\)/MIN_\1=\2; MAX_\1=\3/;
 s/# list \(CONFIG_[^ ]*\) \([^ ][^ ]*\)/LIST_\1=\2/
-' <$FORCE_DEFAULT >.default_val.$$
-    . .default_val.$$
-    rm .default_val.$$
+' <$FORCE_DEFAULT >$objtree/.default_val.$$
+    . $objtree/.default_val.$$
+    rm $objtree/.default_val.$$
   else
     echo "#"
     echo "# No defaults found"
@@ -678,17 +678,18 @@
 
 . $CONFIG_IN
 
-rm -f .config.old
-if [ -f .config ]; then
-	mv .config .config.old
+rm -f $objtree/.config.old
+if [ -f $objtree/.config ]; then
+	mv $objtree/.config $objtree/.config.old
 fi
-mv .tmpconfig .config
-mv .tmpconfig.h include/linux/autoconf.h
+mv $CONFIG   $objtree/.config
+mkdir -p $objtree/include/linux
+mv $CONFIG_H $objtree/include/linux/autoconf.h
 
 echo
 echo "*** End of Linux kernel configuration."
 echo "*** Check the top-level Makefile for additional configuration."
-if [ ! -f .hdepend -o "$CONFIG_MODVERSIONS" = "y" ] ; then
+if [ ! -f $objtree/.hdepend -o "$CONFIG_MODVERSIONS" = "y" ] ; then
     echo "*** Next, you must run 'make dep'."
 else
     echo "*** Next, you may run 'make bzImage', 'make bzdisk', or 'make install'."
diff -Nru a/scripts/Menuconfig b/scripts/Menuconfig
--- a/scripts/Menuconfig	Fri Jun 28 00:09:08 2002
+++ b/scripts/Menuconfig	Fri Jun 28 00:09:08 2002
@@ -74,7 +74,8 @@
 # - Implemented new functions: define_tristate(), define_int(), define_hex(),
 #   define_string(), dep_bool().
 # 
-
+# 27 July 2002, Sam Ravnborg <sam@ravnborg.org>
+# - All files are now located in $objtree
 
 #
 # Change this to TRUE if you prefer all kernel options listed
@@ -128,7 +129,7 @@
 #
 function comment () {
 	comment_ctr=$[ comment_ctr + 1 ]
-	echo -ne "': $comment_ctr' '--- $1' " >>MCmenu
+	echo -ne "': $comment_ctr' '--- $1' " >>$MCMENU
 }
 
 #
@@ -166,9 +167,9 @@
 	n)	flag=" " ;;
 	esac
 
-	echo -ne "'$2' '[$flag] $1$info' " >>MCmenu
+	echo -ne "'$2' '[$flag] $1$info' " >>$MCMENU
 
-	echo -e "function $2 () { l_bool '$2' \"\$1\" ;}\n" >>MCradiolists
+	echo -e "function $2 () { l_bool '$2' \"\$1\" ;}\n" >>$MCRADIO
 }
 
 #
@@ -190,10 +191,10 @@
 		*) flag=" " ;;
 		esac
 	
-		echo -ne "'$2' '<$flag> $1$info' " >>MCmenu
+		echo -ne "'$2' '<$flag> $1$info' " >>$MCMENU
 	
 		echo -e "
-		function $2 () { l_tristate '$2' \"\$1\" ;}" >>MCradiolists
+		function $2 () { l_tristate '$2' \"\$1\" ;}" >>$MCRADIO
 	fi
 }
 
@@ -284,9 +285,9 @@
 function int () {
 	set_x_info "$2" "$3"
 
-	echo -ne "'$2' '($x) $1$info' " >>MCmenu
+	echo -ne "'$2' '($x) $1$info' " >>$MCMENU
 
-	echo -e "function $2 () { l_int '$1' '$2' '$3' '$x' ;}" >>MCradiolists
+	echo -e "function $2 () { l_int '$1' '$2' '$3' '$x' ;}" >>$MCRADIO
 }
 
 #
@@ -296,9 +297,9 @@
 	set_x_info "$2" "$3"
 	x=${x##*[x,X]}
 
-	echo -ne "'$2' '($x) $1$info' " >>MCmenu
+	echo -ne "'$2' '($x) $1$info' " >>$MCMENU
 
-	echo -e "function $2 () { l_hex '$1' '$2' '$3' '$x' ;}" >>MCradiolists
+	echo -e "function $2 () { l_hex '$1' '$2' '$3' '$x' ;}" >>$MCRADIO
 }
 
 #
@@ -307,9 +308,9 @@
 function string () {
 	set_x_info "$2" "$3"
 
-	echo -ne "'$2' '     $1: \"$x\"$info' " >>MCmenu
+	echo -ne "'$2' '     $1: \"$x\"$info' " >>$MCMENU
 
-	echo -e "function $2 () { l_string '$1' '$2' '$3' '$x' ;}" >>MCradiolists
+	echo -e "function $2 () { l_string '$1' '$2' '$3' '$x' ;}" >>$MCRADIO
 }
 
 #
@@ -343,11 +344,11 @@
 
 	: ${current:=$default}
 
-	echo -ne "'$firstchoice' '($current) $title' " >>MCmenu
+	echo -ne "'$firstchoice' '($current) $title' " >>$MCMENU
 
 	echo -e "
 	function $firstchoice () \
-		{ l_choice '$title' \"$choices\" \"$current\" ;}" >>MCradiolists
+		{ l_choice '$title' \"$choices\" \"$current\" ;}" >>$MCRADIO
 }
 
 } # END load_functions()
@@ -367,7 +368,7 @@
    #first escape regexp special characters in the argument:
    var=$(echo "$1"|sed 's/[][\/.^$*]/\\&/g')
    #now pick out the right help text:
-   text=$(cat /dev/null $(find . -name Config.help) |
+   text=$(cat /dev/null $(find $srctree -name Config.help) |
           sed -n "/^$var[ 	]*\$/,\${
                         /^$var[ 	]*\$/c\\
 ${var}:\\
@@ -392,15 +393,16 @@
 # Activate a help dialog.
 #
 function help () {
-	if extract_help $1 >help.out
+	HELP=$objtree/help.out
+	if extract_help $1 >$HELP
 	then
 		$DIALOG	--backtitle "$backtitle" --title "$2"\
-			--textbox help.out $ROWS $COLS
+			--textbox $HELP $ROWS $COLS
 	else
 		$DIALOG	--backtitle "$backtitle" \
-			--textbox help.out $ROWS $COLS
+			--textbox $HELP $ROWS $COLS
 	fi
-	rm -f help.out
+	rm -f $HELP
 }
 
 #
@@ -408,7 +410,7 @@
 #
 function show_readme () {
 	$DIALOG --backtitle "$backtitle" \
-		--textbox scripts/README.Menuconfig $ROWS $COLS
+		--textbox $srctree/scripts/README.Menuconfig $ROWS $COLS
 }
 
 #
@@ -420,15 +422,15 @@
 			--backtitle '$backtitle' \
 			--menu '$menu_instructions' \
 			$ROWS $COLS $((ROWS-10)) \
-			'$default' " >MCmenu
-	>MCradiolists
+			'$default' " >$MCMENU
+	>$MCRADIO
 }
 
 #
 # Add a submenu option to the menu currently under construction.
 #
 function submenu () {
-	echo -ne "'activate_menu $2' '$1  --->' " >>MCmenu
+	echo -ne "'activate_menu $2' '$1  --->' " >>$MCMENU
 }
 
 #
@@ -466,9 +468,9 @@
 	    *)   flag=' ' ;;
 	    esac
  
-	    echo -ne "'$2' '<$flag> $1$info' " >>MCmenu
+	    echo -ne "'$2' '<$flag> $1$info' " >>$MCMENU
  
-	    echo -e "function $2 () { l_mod_bool '$2' \"\$1\" ;}" >>MCradiolists
+	    echo -e "function $2 () { l_mod_bool '$2' \"\$1\" ;}" >>$MCRADIO
 	fi
 }
 
@@ -534,9 +536,9 @@
 		if $DIALOG --title "$1" \
 			--backtitle "$backtitle" \
 			--inputbox "$inputbox_instructions_int" \
-			10 75 "$4" 2>MCdialog.out
+			10 75 "$4" 2>$MCDIALOG
 		then
-			answer="`cat MCdialog.out`"
+			answer="`cat $MCDIALOG`"
 			answer="${answer:-$3}"
 
 			# Semantics of + and ? in GNU expr changed, so
@@ -568,9 +570,9 @@
 		if $DIALOG --title "$1" \
 			--backtitle "$backtitle" \
 			--inputbox "$inputbox_instructions_hex" \
-			10 75 "$4" 2>MCdialog.out
+			10 75 "$4" 2>$MCDIALOG
 		then
-			answer="`cat MCdialog.out`"
+			answer="`cat $MCDIALOG`"
 			answer="${answer:-$3}"
 			answer="${answer##*[x,X]}"
 
@@ -601,9 +603,9 @@
 		if $DIALOG --title "$1" \
 			--backtitle "$backtitle" \
 			--inputbox "$inputbox_instructions_string" \
-			10 75 "$4" 2>MCdialog.out
+			10 75 "$4" 2>$MCDIALOG
 		then
-			answer="`cat MCdialog.out`"
+			answer="`cat $MCDIALOG`"
 			answer="${answer:-$3}"
 
 			#
@@ -658,9 +660,9 @@
 		if $DIALOG --title "$title" \
 			--backtitle "$backtitle" \
 			--radiolist "$radiolist_instructions" \
-			15 70 6 $list 2>MCdialog.out
+			15 70 6 $list 2>$MCDIALOG
 		then
-			choice=`cat MCdialog.out`
+			choice=`cat $MCDIALOG`
 			break
 		fi
 
@@ -700,10 +702,10 @@
 BEGIN {
 	menu_no = 0
 	comment_is_option = 0
-	parser("'$CONFIG_IN'","MCmenu0")
+	parser("'$CONFIG_IN'","'$objtree'","'$MCMENUMAIN'")
 }
 
-function parser(ifile,menu) {
+function parser(ifile,menudir,mainmenu) {
 
 	while (getline <ifile) {
 		if ($1 == "mainmenu_option") {
@@ -714,28 +716,28 @@
 			sub($1,"",$0)
 			++menu_no
 
-			printf("submenu %s MCmenu%s\n", $0, menu_no) >>menu
+			printf("submenu %s MCmenu%s\n", $0, menu_no) >>mainmenu
 
-			newmenu = sprintf("MCmenu%d", menu_no);
+			newmenu = sprintf("%s/MCmenu%d", menudir, menu_no);
 			printf( "function MCmenu%s () {\n"\
 				"default=$1\n"\
 				"menu_name %s\n",\
 				 menu_no, $0) >newmenu
 
-			parser(ifile, newmenu)
+			parser(ifile, menudir, newmenu)
 		}
 		else if ($0 ~ /^#|\$MAKE|mainmenu_name/) {
-			printf("") >>menu
+			printf("") >>mainmenu
 		}
 		else if ($1 ~ "endmenu") {
-			printf("}\n") >>menu
+			printf("}\n") >>mainmenu
 			return
 		} 
 		else if ($1 == "source") {
-			parser($2,menu)
+			parser($2,menudir,mainmenu)
 		}
 		else {
-			print >>menu
+			print >>mainmenu
 		}
 	}
 }'
@@ -747,23 +749,23 @@
 function parser2 () {
 callawk '
 BEGIN {
-	parser("'$CONFIG_IN'","MCmenu0")
+	parser("'$CONFIG_IN'","'$objtree'","'$MCMENUMAIN'")
 }
 
-function parser(ifile,menu) {
+function parser(ifile,menudir,mainmenu) {
 
 	while (getline <ifile) {
 		if ($0 ~ /^#|$MAKE|mainmenu_name/) {
-			printf("") >>menu
+			printf("") >>mainmenu
 		}
 		else if ($1 ~ /mainmenu_option|endmenu/) {
-			printf("") >>menu
+			printf("") >>mainmenu
 		} 
 		else if ($1 == "source") {
-			parser($2,menu)
+			parser($2,menudir,mainmenu)
 		}
 		else {
-			print >>menu
+			print >>mainmenu
 		}
 	}
 }'
@@ -773,11 +775,11 @@
 # Parse all the config.in files into mini scripts.
 #
 function parse_config_files () {
-	rm -f MCmenu*
+	rm -f $objtree/MCmenu*
 
-	echo "function MCmenu0 () {" >MCmenu0
-	echo 'default=$1' >>MCmenu0
-	echo "menu_name 'Main Menu'" >>MCmenu0
+	echo "function MCmenu0 () {" >$MCMENUMAIN
+	echo 'default=$1' >>$MCMENUMAIN
+	echo "menu_name 'Main Menu'" >>$MCMENUMAIN
 
 	if [ "_$single_menu_mode" = "_TRUE" ]
 	then
@@ -786,11 +788,11 @@
 		parser1
 	fi
 
-	echo "comment ''"	>>MCmenu0
-	echo "g_alt_config" 	>>MCmenu0
-	echo "s_alt_config" 	>>MCmenu0
+	echo "comment ''"	>>$MCMENUMAIN
+	echo "g_alt_config" 	>>$MCMENUMAIN
+	echo "s_alt_config" 	>>$MCMENUMAIN
 
-	echo "}" >>MCmenu0
+	echo "}" >>$MCMENUMAIN
 
 	#
 	# These mini scripts must be sourced into the current
@@ -799,12 +801,12 @@
 	# in activate_menu(), among other things.  Once they are
 	# sourced we can discard them.
 	#
-	for i in MCmenu*
+	for i in $objtree/MCmenu*
 	do
 		echo -n "."
-		source ./$i
+		source $i
 	done
-	rm -f MCmenu*
+	rm -f $objtree/MCmenu*
 }
 
 #
@@ -815,12 +817,13 @@
 # dialog commands or recursively call other menus.
 #
 function activate_menu () {
-	rm -f lxdialog.scrltmp
+	MCERROR=$objtree/MCerror
+	rm -f $objtree/lxdialog.scrltmp
 	while true
 	do
 		comment_ctr=0		#So comment lines get unique tags
 
-		$1 "$default" 2> MCerror #Create the lxdialog menu & functions
+		$1 "$default" 2> $MCERROR #Create the lxdialog menu & functions
 
 		if [ "$?" != "0" ]
 		then
@@ -832,7 +835,7 @@
 report:
 
 EOM
-			sed 's/^/ Q> /' MCerror
+			sed 's/^/ Q> /' $MCERROR
 			cat <<EOM
 
 Please report this to the maintainer <mec@shout.net>.  You may also
@@ -845,14 +848,14 @@
 			cleanup
 			exit 1
 		fi
-		rm -f MCerror
+		rm -f $MCERROR
 
-		. ./MCradiolists		#Source the menu's functions
+		. $MCRADIO		#Source the menu's functions
 
-		. ./MCmenu 2>MCdialog.out	#Activate the lxdialog menu
+		. $MCMENU 2>$MCDIALOG	#Activate the lxdialog menu
 		ret=$?
 
-		read selection <MCdialog.out
+		read selection <$MCDIALOG
 
 		case "$ret" in
 		0|3|4|5|6)
@@ -914,7 +917,7 @@
 #
 g_alt_config () {
 	echo -n "get_alt_config 'Load an Alternate Configuration File' "\
-		>>MCmenu
+		>>$MCMENU
 }
 
 #
@@ -922,6 +925,7 @@
 # configuration from it.
 #
 get_alt_config () {
+	HELP=$objtree/help.out
 	set -f ## Switch file expansion OFF
 
 	while true
@@ -933,11 +937,11 @@
 Enter the name of the configuration file you wish to load.  \
 Accept the name shown to restore the configuration you \
 last retrieved.  Leave blank to abort."\
-			11 55 "$ALT_CONFIG" 2>MCdialog.out
+			11 55 "$ALT_CONFIG" 2>$MCDIALOG
 
 		if [ "$?" = "0" ]
 		then
-			ALT_CONFIG=`cat MCdialog.out`
+			ALT_CONFIG=`cat $MCDIALOG`
 
 			[ "_" = "_$ALT_CONFIG" ] && break
 
@@ -952,7 +956,7 @@
 				sleep 2
 			fi
 		else
-			cat <<EOM >help.out
+			cat <<EOM >$HELP
 
 For various reasons, one may wish to keep several different kernel
 configurations available on a single machine.  
@@ -967,12 +971,12 @@
 EOM
 			$DIALOG	--backtitle "$backtitle"\
 				--title "Load Alternate Configuration"\
-				--textbox help.out $ROWS $COLS
+				--textbox $HELP $ROWS $COLS
 		fi
 	done
 
 	set +f ## Switch file expansion ON
-	rm -f help.out MCdialog.out
+	rm -f $HELP $MCDIALOG
 }
 
 #
@@ -980,7 +984,7 @@
 #
 s_alt_config () {
 	echo -n "save_alt_config 'Save Configuration to an Alternate File' "\
-		 >>MCmenu
+		 >>$MCMENU
 }
 
 #
@@ -988,6 +992,7 @@
 # configuration to it.
 #
 save_alt_config () {
+	HELP=$objtree/help.out
 	set -f  ## Switch file expansion OFF
 			
 	while true
@@ -996,11 +1001,11 @@
 			--inputbox "\
 Enter a filename to which this configuration should be saved \
 as an alternate.  Leave blank to abort."\
-			10 55 "$ALT_CONFIG" 2>MCdialog.out
+			10 55 "$ALT_CONFIG" 2>$MCDIALOG
 
 		if [ "$?" = "0" ]
 		then
-			ALT_CONFIG=`cat MCdialog.out`
+			ALT_CONFIG=`cat $MCDIALOG`
 
 			[ "_" = "_$ALT_CONFIG" ] && break
 
@@ -1016,7 +1021,7 @@
 				sleep 2
 			fi
 		else
-			cat <<EOM >help.out
+			cat <<EOM >$HELP
 
 For various reasons, one may wish to keep different kernel
 configurations available on a single machine.  
@@ -1030,12 +1035,12 @@
 EOM
 			$DIALOG	--backtitle "$backtitle"\
 				--title "Save Alternate Configuration"\
-				--textbox help.out $ROWS $COLS
+				--textbox $HELP $ROWS $COLS
 		fi
 	done
 
 	set +f  ## Switch file expansion ON
-	rm -f help.out MCdialog.out
+	rm -f $HELP $MCDIALOG
 }
 
 #
@@ -1261,11 +1266,11 @@
 
 	echo -n "."
 
-	DEF_CONFIG="${1:-.config}"
-	DEF_CONFIG_H="include/linux/autoconf.h"
+	DEF_CONFIG="$objtree/${1:-.config}"
+	DEF_CONFIG_H="$objtree/include/linux/autoconf.h"
 
-	CONFIG=.tmpconfig
-	CONFIG_H=.tmpconfig.h
+	CONFIG=$objtree/.tmpconfig
+	CONFIG_H=$objtree/.tmpconfig.h
 
 	echo "#" >$CONFIG
 	echo "# Automatically generated by make menuconfig: don't edit" >>$CONFIG
@@ -1277,10 +1282,11 @@
 	echo "#define AUTOCONF_INCLUDED" >> $CONFIG_H
 
 	echo -n "."
-	if . $CONFIG_IN >>.menuconfig.log 2>&1
+	if . $CONFIG_IN >>$MENULOG 2>&1
 	then
-		if [ "$DEF_CONFIG" = ".config" ]
+		if [ "$DEF_CONFIG" = "$objtree/.config" ]
 		then
+			mkdir -p $objtree/include/linux
 			mv $CONFIG_H $DEF_CONFIG_H
 		fi
 
@@ -1307,11 +1313,11 @@
 }
 
 cleanup1 () {
-	rm -f MCmenu* MCradiolists MCdialog.out help.out
+	rm -f $MCMENU $MCMENUMAIN $MCRADIO $MCDIALOG $MCHELP
 }
 
 cleanup2 () {
-	rm -f .tmpconfig .tmpconfig.h
+	rm -f $objtree/.tmpconfig $objtree/.tmpconfig.h
 }
 
 set_geometry () {
@@ -1366,7 +1372,13 @@
 Please enter a string value. \
 Use the <TAB> key to move from the input field to the buttons below it."
 
-DIALOG="./scripts/lxdialog/lxdialog"
+DIALOG="$srctree/scripts/lxdialog/lxdialog"
+
+#Menu files
+MCMENU=$objtree/MCmenu
+MCMENUMAIN=$objtree/MCmenu0
+MCRADIO=$objtree/MCradiolists
+MCDIALOG=$objtree/MCdialog.out
 
 kernel_version="${VERSION}.${PATCHLEVEL}.${SUBLEVEL}${EXTRAVERSION}"
 
@@ -1384,8 +1396,8 @@
 fi
 
 DEFAULTS=arch/$ARCH/defconfig
-if [ -f .config ]; then
-  DEFAULTS=.config
+if [ -f $objtree/.config ]; then
+  DEFAULTS=$objtree/.config
 fi
 
 if [ -f $DEFAULTS ]
@@ -1398,7 +1410,8 @@
 
 
 # Fresh new log.
->.menuconfig.log
+MENULOG=$objtree/.menuconfig.log
+>$MENULOG
 
 # Load the functions used by the config.in files.
 echo -n "Preparing scripts: functions" 
@@ -1419,7 +1432,7 @@
 #
 # Read config.in files and parse them into one shell function per menu.
 #
-echo -n ", parsing"
+echo -n ", parsing $CONFIG_IN"
 parse_config_files $CONFIG_IN
 
 echo "done."
@@ -1444,7 +1457,7 @@
 	echo
 	echo "*** End of Linux kernel configuration."
 	echo "*** Check the top-level Makefile for additional configuration."
-	if [ ! -f .hdepend -o "$CONFIG_MODVERSIONS" = "y" ] ; then
+	if [ ! -f $objtree/.hdepend -o "$CONFIG_MODVERSIONS" = "y" ] ; then
 	    echo "*** Next, you must run 'make dep'."
 	else
 	    echo "*** Next, you may run 'make bzImage', 'make bzdisk', or 'make install'."
@@ -1458,8 +1471,8 @@
 fi
 
 # Remove log if empty.
-if [ ! -s .menuconfig.log ] ; then
-	rm -f .menuconfig.log
+if [ ! -s $MENULOG ] ; then
+	rm -f $MENULOG
 fi
 
 exit 0
diff -Nru a/scripts/lxdialog/menubox.c b/scripts/lxdialog/menubox.c
--- a/scripts/lxdialog/menubox.c	Fri Jun 28 00:09:08 2002
+++ b/scripts/lxdialog/menubox.c	Fri Jun 28 00:09:08 2002
@@ -55,7 +55,7 @@
  * would leave mis-synchronized lxdialog.scrltmp files lying around,
  * fscanf would read in 'scroll', and eventually that value would get used.
  */
-
+#include <limits.h>
 #include "dialog.h"
 
 static int menu_width, item_x;
@@ -172,6 +172,7 @@
     int key = 0, button = 0, scroll = 0, choice = 0, first_item = 0, max_choice;
     WINDOW *dialog, *menu;
     FILE *f;
+    char scrltmp[PATH_MAX];
 
     max_choice = MIN (menu_height, item_no);
 
@@ -237,7 +238,8 @@
     item_x = (menu_width - item_x) / 2;
 
     /* get the scroll info from the temp file */
-    if ( (f=fopen("lxdialog.scrltmp","r")) != NULL ) {
+    sprintf(scrltmp, "%s/lxdialog.scrltmp", getenv("objtree"));
+    if ( (f=fopen(scrltmp,"r")) != NULL ) {
 	if ( (fscanf(f,"%d\n",&scroll) == 1) && (scroll <= choice) &&
 	     (scroll+max_choice > choice) && (scroll >= 0) &&
 	     (scroll+max_choice <= item_no) ) {
@@ -246,7 +248,7 @@
 	    fclose(f);
 	} else {
 	    scroll=0;
-	    remove("lxdialog.scrltmp");
+	    remove(scrltmp);
 	    fclose(f);
 	    f=NULL;
 	}
@@ -400,7 +402,7 @@
 	case 'n':
 	case 'm':
 	    /* save scroll info */
-	    if ( (f=fopen("lxdialog.scrltmp","w")) != NULL ) {
+	    if ( (f=fopen(scrltmp,"w")) != NULL ) {
 		fprintf(f,"%d\n",scroll);
 		fclose(f);
 	    }
@@ -427,7 +429,7 @@
 	    else
             	fprintf(stderr, "%s\n", items[(scroll + choice) * 2]);
 
-	    remove("lxdialog.scrltmp");
+	    remove(scrltmp);
 	    return button;
 	case 'e':
 	case 'x':
@@ -438,6 +440,6 @@
     }
 
     delwin (dialog);
-    remove("lxdialog.scrltmp");
+    remove(scrltmp);
     return -1;			/* ESC pressed */
 }

Re: [PATCH] kconfig: menuconfig and config uses $objtree

[Keith Owens]

On Fri, 28 Jun 2002 00:14:52 +0200, 
Sam Ravnborg <sam@ravnborg.org> wrote:
>In order to prepare for separate obj and src trees make use of $objtree
>within scripts/Menuconfig and scripts/Configure.
>All temporary and all result files are located in directory pointed at
>by $objtree.
>
>This functionality is foreseen useful for both current kbuild and kbuild-2.5

Wrong approach.  This messes up kbuild 2.5.  The config tools should
not know where the files are being read from or written to, you have
hard coded knowledge about the tree structure into the config system.

kbuild 2.5 handles this by constructing a set of symlinks then invoking
the configure system under those symlinks, followed by copying any
results to their destination.  The symlink tree completely isolates
the config system from any knowledge of where its inpuuts and outputs
really are, everything looks local.

You have a 750+ line patch to imbed tree knowledge into configure, that
knowledge will have to be duplicated for any new CML tools.  kbuild 2.5
does it in a few lines of scripts/Makefile-2.5 which automatically
works for any new CML code.

Re: [PATCH] kconfig: menuconfig and config uses $objtree

[Sam Ravnborg]

On Fri, Jun 28, 2002 at 12:19:00PM +1000, Keith Owens wrote:
> On Fri, 28 Jun 2002 00:14:52 +0200, 
> Sam Ravnborg <sam@ravnborg.org> wrote:
> >In order to prepare for separate obj and src trees make use of $objtree
> >within scripts/Menuconfig and scripts/Configure.
> >All temporary and all result files are located in directory pointed at
> >by $objtree.
> >
> >This functionality is foreseen useful for both current kbuild and kbuild-2.5
> 
> Wrong approach.  This messes up kbuild 2.5.  The config tools should
> not know where the files are being read from or written to, you have
> hard coded knowledge about the tree structure into the config system.
Thanks for the feedback.
And I agree with you 100% that the config tools shall not
know where the files are being read, nor where they are being written.

> kbuild 2.5 handles this by constructing a set of symlinks then invoking
> the configure system under those symlinks, followed by copying any
> results to their destination.  The symlink tree completely isolates
> the config system from any knowledge of where its inpuuts and outputs
> really are, everything looks local.
I noticed this 'magic' in kbuild-2.5.
As you see a lot of cruft is required to circumvent the fact that the
current config tools are hardcoded to read from current directory
and hardcoded to write to current directory.

> You have a 750+ line patch to imbed tree knowledge into configure, that
> knowledge will have to be duplicated for any new CML tools.  kbuild 2.5
> does it in a few lines of scripts/Makefile-2.5 which automatically
> works for any new CML code.
Did you look in the patch?
It basically teach the config tools that the SRC are no longer
in current directory but pointed out by $srctree, that output files
are pointed out by $objtree, and temporary files the same place.

No nasty tricks with sym-lnks required, no copy files around before
or after the config tools are used. No specific directories that
needs to be created beforehand.
Indeed my approach is a number of lines - but that on the other hand
simplify the usage of the config tools.

But I see your point that we should avoid hardcoding too much
knowledge in the config tools, and I may change the patch to
use command-line parameters to specify SRC and OBJ dirs.

	Sam

Re: [PATCH] kconfig: menuconfig and config uses $objtree

[Keith Owens]

On Fri, 28 Jun 2002 19:28:07 +0200, 
Sam Ravnborg <sam@ravnborg.org> wrote:
>It basically teach the config tools that the SRC are no longer
>in current directory but pointed out by $srctree, that output files
>are pointed out by $objtree, and temporary files the same place.
>
>No nasty tricks with sym-lnks required, no copy files around before
>or after the config tools are used. No specific directories that
>needs to be created beforehand.
>Indeed my approach is a number of lines - but that on the other hand
>simplify the usage of the config tools.
>
>But I see your point that we should avoid hardcoding too much
>knowledge in the config tools, and I may change the patch to
>use command-line parameters to specify SRC and OBJ dirs.

What happens when you want to support multiple source trees?  Your
approach prevents the use of multiple source trees, either shadow or
separate (add on) code and breaks kbuild 2.5.  My approach puts all the
complexity (once) in the makefile, not replicated over multiple CML
programs.

What happens when the config data is not in monolithic files but is
supplied in per-driver files (driver.inf)?  Linus wants that feature
eventually.  Note that driver.inf will contain more than just config
data, it will contain all the data required to build a driver.  With
your approach every CML program would have to be changed to understand
the format of the driver.inf files, replicating the code over multiple
parsers.  With my approach you need one program that extracts the
relevant data for config and builds the config tree, then the existing
CML programs run unchanged.

Do it once in the makefile.  Do not embed the knowledge about the
source of the config data in every CML program.

Re: [PATCH] kconfig: menuconfig and config uses $objtree

[Sam Ravnborg]

On Sat, Jun 29, 2002 at 11:50:41AM +1000, Keith Owens wrote:
> What happens when you want to support multiple source trees?
Nothing!

> Your
> approach prevents the use of multiple source trees, either shadow or
> separate (add on) code and breaks kbuild 2.5.  My approach puts all the
> complexity (once) in the makefile, not replicated over multiple CML
> programs.
Could you please go read the patch..
There is NO change in functionality in the config tools, the only
thing that is added is the possibility to tell the config tools that
the src is located somewhere else than current directory - the same
for the output files.

> What happens when the config data is not in monolithic files but is
> supplied in per-driver files (driver.inf)?  Linus wants that feature
> eventually.  Note that driver.inf will contain more than just config
> data, it will contain all the data required to build a driver.  With
> your approach every CML program would have to be changed to understand
> the format of the driver.inf files, replicating the code over multiple
> parsers.  With my approach you need one program that extracts the
> relevant data for config and builds the config tree, then the existing
> CML programs run unchanged.
So what you actually try to say is that the better approach is to
copy files to a common place, eventually extracted from different
source trees and eventually extracted from driver.inf files.

So this is where we disagree:
Every CML program
-----------------
There are 3 CML programs within the kernel tree (Configure, menuconfig
and xconfig). To me the best thing that could happen was that they
disappeared, being replaced by a single config tool - that provided
the same type of interfaces. This tools we could extend to do a little
more semantic checks etc.
There exist several not-in-the-tree config tools, and they just have
to adapt. No-one told them they could rely on current behaviour
forever.
I hope that one of the existing out-of-tree tools (mconfig, llc, autoconf,
CML2, GCML2 - others?) one day will get mature enough to replace the
existing tools.

driver.inf / driver.conf
------------------------
One could extract the information before running the config tool,
or one could let the config tool do the job.
I prefer the latter since I see no point in having to put knowledge
of the driver.inf format in more than one place.

Create a shadow structure for config tools to use
-------------------------------------------------
The only sole reason why kbuild.2-5 needs to create a shadow tree
of all the config related files is simply that you have decided
what you consider the best way to support shadow trees are.
So in our discussion about shadow-tress I recall you mentioned 
several times that using a built-only tree of src-files would create
a lot of problems when changes were made, and you had to distribute
changes back in the original trees.
My point then was that changes were always made in the original tree.
And now I see that you use the exact same apporach for config-files
within kbuild-2.5. So do you agree that creating a built-only tree
suddenly becomes an OK solution?

I disagree with the approach you have chosen to support shadow trees.
I have stated before that your approach with intiminate knowledge
of shadow trees built-in to kbuild resulted in too much complexity.
This is a good example of such complexity, that a tree needs to be
built only with the purpose to support the config tools.

Therefor I see a good point optimizing the current config tools
to current kbuild. I see no point in keeping the current behaviour
if this is only for the sake of kbuild-2.5.

	Sam

Re: [PATCH] kconfig: menuconfig and config uses $objtree

[Keith Owens]

On Sat, 29 Jun 2002 09:26:01 +0200, 
Sam Ravnborg <sam@ravnborg.org> wrote:
>So in our discussion about shadow-tress I recall you mentioned 
>several times that using a built-only tree of src-files would create
>a lot of problems when changes were made, and you had to distribute
>changes back in the original trees.
>My point then was that changes were always made in the original tree.
>And now I see that you use the exact same apporach for config-files
>within kbuild-2.5. So do you agree that creating a built-only tree
>suddenly becomes an OK solution?

You are confusing two completely different cases.  Config reads from a
lot of files and generates one file.  Kernel build both reads and
writes lots of files, plus the developer edits files as they create
their code.  Different problems require different solutions.

Creating a set of symlinks in the object tree to point to every source
file is possible but horribly slow!  On my build machine, creating
10,300 symlinks takes 90 seconds before you can even start compiling [*].
In contrast, all of the kbuild 2.5 processing (phases 1 through 4) on
the same machine takes 9 seconds before you start compiling.

I use symlinks for CML because there are far fewer files and the
symlink tree only has to be built when make *config is requested.
There are also several CML programs that would have to be changed each
time the tree structure changed, code replication is bad.

I do not use symlinks for the main build because they are too slow.
Especially when you include the overhead of resynchronising the source
symlinks on every build.  It has to be redone every time because the
set of source files may have changed.

Re: [kbuild-devel] Re: [PATCH] kconfig: menuconfig and config uses $objtree

[Greg Banks]

Sam Ravnborg wrote:
> 
> Every CML program
> -----------------
> There are 3 CML programs within the kernel tree (Configure, menuconfig
> and xconfig). To me the best thing that could happen was that they
> disappeared, being replaced by a single config tool - that provided
> the same type of interfaces. This tools we could extend to do a little
> more semantic checks etc.

<sigh> if only...

> There exist several not-in-the-tree config tools, and they just have
> to adapt. No-one told them they could rely on current behaviour
> forever.

Speaking as the author of one of these, I'm willing to deal with
this behaviour change.

> I hope that one of the existing out-of-tree tools (mconfig, llc, autoconf,
> CML2, GCML2 - others?) one day will get mature enough to replace the
> existing tools.

I don't think maturity is the issue, or CML2 would have been merged by now.

> Create a shadow structure for config tools to use
> -------------------------------------------------
> The only sole reason why kbuild.2-5 needs to create a shadow tree
> of all the config related files is simply that you have decided
> what you consider the best way to support shadow trees are.
> So in our discussion about shadow-tress I recall you mentioned
> several times that using a built-only tree of src-files would create
> a lot of problems when changes were made, and you had to distribute
> changes back in the original trees.
> My point then was that changes were always made in the original tree.
> And now I see that you use the exact same apporach for config-files
> within kbuild-2.5. So do you agree that creating a built-only tree
> suddenly becomes an OK solution?

                     Keith Owens      Sam Ravnborg
               +-----------------------------------------
symlink tree   |
for source     |        bad             good
               |
symlink tree   |       good              bad
for config     | 


As for me, I'm agnostic.  In GCML2, getting from the argument to the
"source" statement to an argument to fopen(3) is by far the least
of the problems caused by having to parse CML1 rules.

> Therefor I see a good point optimizing the current config tools
> to current kbuild. I see no point in keeping the current behaviour
> if this is only for the sake of kbuild-2.5.

Agreed.

Greg.
-- 
the price of civilisation today is a courageous willingness to prevail,
with force, if necessary, against whatever vicious and uncomprehending
enemies try to strike it down.	   - Roger Sandall, The Age, 28Sep2001.

Re: [PATCH] kconfig: menuconfig and config uses $objtree

[Roman Zippel]

Hi,

On Sat, 29 Jun 2002, Keith Owens wrote:

> What happens when you want to support multiple source trees?

First we should answer the question, why kbuild support for multiple
source trees is such a must have feature? So far I haven't seen a
satisfying answer, that would justify a big increase in kbuild complexity.
Only very few people would need such a feature and often there are other
ways to archive almost the same.
If such a feature is really badly needed, I think it's better to implement
it first as a seperate tool, which synchronizes multiple source dirs into
a single dir. This is not as efficient, as kbuild has to recheck the
single dir, but most of it should be in the cache, so it shouldn't be that
bad. On the other hand it should be easy to integrate in whatever kbuild
system. If there should be a huge demand for a better integration, we can
still do this later.

> What happens when the config data is not in monolithic files but is
> supplied in per-driver files (driver.inf)?  Linus wants that feature
> eventually.  Note that driver.inf will contain more than just config
> data, it will contain all the data required to build a driver.  With
> your approach every CML program would have to be changed to understand
> the format of the driver.inf files, replicating the code over multiple
> parsers.  With my approach you need one program that extracts the
> relevant data for config and builds the config tree, then the existing
> CML programs run unchanged.

The simple answer is to replace all the parsers with a single library,
which is what I'm currently working on. Maintaining multiple config
formats is just silly.

bye, Roman

Re: [kbuild-devel] [PATCH] kconfig: menuconfig and config uses $objtree

[Greg Banks]

Sam Ravnborg wrote:
> 
> In order to prepare for separate obj and src trees make use of $objtree
> within scripts/Menuconfig and scripts/Configure.
> All temporary and all result files are located in directory pointed at
> by $objtree.
> 
> This functionality is foreseen useful for both current kbuild and kbuild-2.5

Interesting, but there's an alternative approach.  Let the scripts dump
any files they like into the current directory, but move the current
directory to be the *object* directory not the source directory.  Then
all you need to change are the places where the arch config.in files are
initially included, and to override the "source" statement to look relative
to $srctree not the current directory.  That last can be done like this:

xsource ()
{
    builtin source $srctree/$1
}
shopt -s expand_aliases
alias source=xsource

So the scripts do not even need to know about object directory and source
directory, they only need to know that there is a source directory which
can be separate from the current directory.  This behaviour is closer to
the way autoconf behaves with a separate object directory.

Greg.
-- 
the price of civilisation today is a courageous willingness to prevail,
with force, if necessary, against whatever vicious and uncomprehending
enemies try to strike it down.	   - Roger Sandall, The Age, 28Sep2001.

Re: [kbuild-devel] [PATCH] kconfig: menuconfig and config uses $objtree

[Keith Owens]

On Fri, 28 Jun 2002 18:07:45 +1000, 
Greg Banks <gnb@alphalink.com.au> wrote:
>Sam Ravnborg wrote:
>> 
>> In order to prepare for separate obj and src trees make use of $objtree
>> within scripts/Menuconfig and scripts/Configure.
>> All temporary and all result files are located in directory pointed at
>> by $objtree.
>
>Interesting, but there's an alternative approach.  Let the scripts dump
>any files they like into the current directory, but move the current
>directory to be the *object* directory not the source directory.  Then
>all you need to change are the places where the arch config.in files are
>initially included, and to override the "source" statement to look relative
>to $srctree not the current directory.  That last can be done like this:

You are still forcing all the CML code to know about the difference
between source and object trees and to handle multiple source trees.
With that approach, the knowledge has to be embedded in every CML
program, and changed every time the tree structure changes.

It is far better to retain the existing CML design which assumes that
there is only one tree.  Then use symlinks to hide the real tree
structure from CML.  That gives us the flexibility to change the tree
structure without changing every CML program.

Notice that kbuild 2.5 handles separate source and object trees and
even multiple source trees with _no_ changes to CML code.  The only
change to CML in kbuild 2.5 is to add Ghozlane Toumi's extra config
targets.  scripts/Makefile-2.5 hides all the complexity of separate
source and object and multiple source trees from both CML1 and CML2.

Re: [kbuild-devel] [PATCH] kconfig: menuconfig and config uses $objtree

[Greg Banks]

Keith Owens wrote:
> 
> On Fri, 28 Jun 2002 18:07:45 +1000,
> Greg Banks <gnb@alphalink.com.au> wrote:
> >Sam Ravnborg wrote:
> >>
> >> In order to prepare for separate obj and src trees make use of $objtree
> >> within scripts/Menuconfig and scripts/Configure.
> >> All temporary and all result files are located in directory pointed at
> >> by $objtree.
> >
> >Interesting, but there's an alternative approach. [...]
> 
> You are still forcing all the CML code to know about the difference
> between source and object trees and to handle multiple source trees.

Yes.

> With that approach, the knowledge has to be embedded in every CML
> program, and changed every time the tree structure changes.

I haven't commented on whether Sam's patch is good architecture, just
that it could be implemented in several hundred fewer lines.

> It is far better to retain the existing CML design which assumes that
> there is only one tree.  Then use symlinks to hide the real tree
> structure from CML.  That gives us the flexibility to change the tree
> structure without changing every CML program.

Sure.  Assuming Sam's script will take the source director(y|ies) as an
argument, they will work with this approach but they will also work with
whatever approach Kai takes.

> Notice that kbuild 2.5 handles separate source and object trees and
> even multiple source trees with _no_ changes to CML code.  The only
> change to CML in kbuild 2.5 is to add Ghozlane Toumi's extra config
> targets.  scripts/Makefile-2.5 hides all the complexity of separate
> source and object and multiple source trees from both CML1 and CML2.

Great, another reason to use kbuild 2.5.

Greg.
-- 
the price of civilisation today is a courageous willingness to prevail,
with force, if necessary, against whatever vicious and uncomprehending
enemies try to strike it down.	   - Roger Sandall, The Age, 28Sep2001.