2002-06-27 22:07:54

by Sam Ravnborg

[permalink] [raw]
Subject: [PATCH] kconfig: menuconfig and config uses $objtree

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 [email protected] 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 <[email protected]>
+# - 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 <[email protected]>. 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 */
}


2002-06-28 02:16:58

by Keith Owens

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

On Fri, 28 Jun 2002 00:14:52 +0200,
Sam Ravnborg <[email protected]> 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.

2002-06-28 17:22:18

by Sam Ravnborg

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

On Fri, Jun 28, 2002 at 12:19:00PM +1000, Keith Owens wrote:
> On Fri, 28 Jun 2002 00:14:52 +0200,
> Sam Ravnborg <[email protected]> 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

2002-06-29 01:48:35

by Keith Owens

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

On Fri, 28 Jun 2002 19:28:07 +0200,
Sam Ravnborg <[email protected]> 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.

2002-06-29 07:19:30

by Sam Ravnborg

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

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

2002-06-29 08:20:55

by Keith Owens

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

On Sat, 29 Jun 2002 09:26:01 +0200,
Sam Ravnborg <[email protected]> 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.

2002-06-29 15:34:56

by Roman Zippel

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

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