Arch specific/multiple Configure.help files?
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 7 lines · [email protected] wrote:
I went ahead and implemented the change last night anyway and I will submit the patches and see if it will be accepted or not. The idea is that it first check in
arch/$ARCH/Configure.helpand if the file or the help is not found there,
checkDocumentation/Configure.help.
Quoted 6 lines
I believe there is an advantage from a maintenance point of view. It least for our CRIS architecture, I don't think it's any benefit to "bloat" the
Documentation/Configure.helpwith a lot ofCONFIG_ETRAXentries for the various hardware inerfaces when the help and config can be kept locally.
This was already discussed on kbuild list.
It is better to have only 1 Configure.help. This help translation of
the file and help busy developers. They should not rewrite texts
in every Configure.help.
If you should provide a special help on a specific ARCH you could
modify the symbols:
instead of
: bool 'std IPC support' CONFIG_IPC
you can do:
: bool 'arch specific IPC help' CONFIG_IPC_STRANGE_ARCH : define_bool CONFIG_IPC CONFIG_IPC_STRANGE_ARCH
ESR CML2 have the defualt path for Configure.help build in the rules files, but it can be overriden by command options to use an other Configure.help (the format do not change).
It is also designed so that a distribution can include a translation of Configure.help. (But we don't expect to include translation in std linux kernel)
Quoted 5 lines
BTW: I added this to
scripts/Configureandscripts/Menuconfigbut I know to little tcl/tk to get it to work for the xconfig case. The variable $ARCH was not found and I don't know how to make it get it from the environment variables.
$ARCH is set on the top of the main Makefile. You can copy the small shell script from here.
giacomo
Quoted 2 lines
/Johan
----- Original Message -----
From: Giacomo Catenazzi <[email protected]>
To: <[email protected]>
Cc: Erik Mouw <[email protected]>; Rogier Wolff <[email protected]>; <[email protected]>
Sent: Friday, April 06, 2001 8:58 AM
Subject: Re: Arch specific/multiple Configure.help files?
Quoted 15 lines
Quoted 7 lines · [email protected] wrote:
I went ahead and implemented the change last night anyway and I will submit the patches and see if it will be accepted or not. The idea is that it first check in
arch/$ARCH/Configure.helpand if the file or the help is not found there,
checkDocumentation/Configure.help.Quoted 6 lines
I believe there is an advantage from a maintenance point of view. It least for our CRIS architecture, I don't think it's any benefit to "bloat" the
Documentation/Configure.helpwith a lot ofCONFIG_ETRAXentries for the various hardware inerfaces when the help and config can be kept locally.
Quoted 4 lines
This was already discussed on kbuild list.
It is better to have only 1 Configure.help. This help translation of the file and help busy developers. They should not rewrite texts in every Configure.help.
I can't see that 1 file makes it easier.
The same help text is only present in one file,
either arch/$ARCH/Configure.help orDocumentation/Configure.help
The help system first checks the file in arch/$ARCH and if the help is not present there it checks the one in Documentation/
Quoted 6 lines
If you should provide a special help on a specific ARCH you could modify the symbols: instead of
: bool 'std IPC support'CONFIG_IPC
you can do:
: bool 'arch specific IPC help'CONFIG_IPC_STRANGE_ARCH:define_boolCONFIG_IPCCONFIG_IPC_STRANGE_ARCH
Don't know if you missunderstood me or if I missunderstand you here.
The typical use for the arch specific help file would only cover the arch specific CONFIG options (although it could "override" the general help text in Documentation/Configure.help with an arch specific one, but if you do that I guess you're doing something wrong)
Quoted 3 lines
ESR CML2 have the defualt path for Configure.help build in the rules files, but it can be overriden by command options to use an other Configure.help (the format do not change).
I want to be able to use two help files.
Quoted 5 lines
It is also designed so that a distribution can include a translation of Configure.help. (But we don't expect to include translation in std linux kernel)
Quoted 8 lines
Quoted 5 lines
BTW: I added this to
scripts/Configureandscripts/Menuconfigbut I know to little tcl/tk to get it to work for the xconfig case. The variable $ARCH was not found and I don't know how to make it get it from the environment variables.$ARCH is set on the top of the main
Makefile. You can copy the small shell script from here.
I found the $env(ARCH) syntax by searching the net a little so now make xconfig works with 2 helpfiles as well.
Quoted 3 lines
giacomo
Quoted 1 line
/Johan
/Johan
Quoted 10 lines · [email protected] wrote:
Quoted 5 lines
This was already discussed on kbuild list.
It is better to have only 1 Configure.help. This help translation of the file and help busy developers. They should not rewrite texts in every Configure.help.I can't see that 1 file makes it easier.
The same help text is only present in one file,
eitherarch/$ARCH/Configure.helporDocumentation/Configure.help
Ok, if you use both files.
Better a single file because:
- I18n support. (But not a big issue for us).
- CML2 merges all arch configurations in one file (really in 4 file:
rules, menu strings, ...)
Thus because we merge also configuration, I think that it is
better
not to split the helps.
- IIRC there is only few ARCH specific configuration, thus we don't
reduce the size of che Configure.help
Note that the arch/config.in have to much configuration item (but they repeat in (nearly) all arch/config.in files, thus
you
should count only the really arch specific item.
I would prefer to have config.in and help file togheter. But in the
discussion in kbuild list, it come that is is better to merge all configuration in one file and the strings in an other (and thus
not to merge Configure.help to not heve a very huge file).
What are the advanteget to split the Configure.help?
Quoted 13 lines
The help system first checks the file in
arch/$ARCHand if the help is not present there it checks the one inDocumentation/Quoted 6 lines
If you should provide a special help on a specific ARCH you could modify the symbols: instead of
: bool 'std IPC support'CONFIG_IPC
you can do:
: bool 'arch specific IPC help'CONFIG_IPC_STRANGE_ARCH:define_boolCONFIG_IPCCONFIG_IPC_STRANGE_ARCH
Quoted 7 lines
Don't know if you missunderstood me or if I missunderstand you here.
The typical use for the arch specific help file would only cover the arch specific CONFIG options (although it could "override" the general help text inDocumentation/Configure.helpwith an arch specific one, but if you do that I guess you're doing something wrong)
I think I missunderstood you. But this was the big issue for splitting Configure.help. (Thus if an developer should use at arch specific help, he should use this method)
Quoted 6 lines
Quoted 4 lines
ESR CML2 have the defualt path for Configure.help build in the rules files, but it can be overriden by command options to use an other Configure.help (the format do not change).
I want to be able to use two help files.
I think it is not a big issue. In Makefile we can
: cat Conf.help.1 Conf.help2 > .Conf.help
giacomo
----- Original Message -----
From: Giacomo Catenazzi <[email protected]>
To: <[email protected]>
Cc: <[email protected]>
Sent: Friday, April 06, 2001 09:44
Subject: Re: Arch specific/multiple Configure.help files?
Quoted 12 lines
Quoted 10 lines · [email protected] wrote:
Quoted 5 lines
This was already discussed on kbuild list.
It is better to have only 1 Configure.help. This help translation of the file and help busy developers. They should not rewrite texts in every Configure.help.I can't see that 1 file makes it easier.
The same help text is only present in one file,
eitherarch/$ARCH/Configure.helporDocumentation/Configure.help
Quoted 4 lines
Ok, if you use both files.
Better a single file because:
- I18n support. (But not a big issue for us).
I must admit that I haven't got a clue what that is:-)
Quoted 5 lines
- CML2 merges all arch configurations in one file (really in 4 file:
rules, menu strings, ...)
Thus because we merge also configuration, I think that it is
better not to split the helps.
If this is solved by merging two files or if the config system really uses two files doesn't really matter to me. Merging files is probably a better approach if having non-centralised help files can be accepted.
Quoted 7 lines
- IIRC there is only few ARCH specific configuration, thus we don't
reduce the size of che Configure.help
Note that thearch/config.inhave to much configuration item (but they repeat in (nearly) allarch/config.infiles, thus
you
should count only the really arch specific item.
Here are some results:
$ wc arch/cris/Configure.help
621 4424 28373 arch/cris/Configure.help
$ wc Documentation/Configure.help
17480 121037 773694 Documentation/Configure.help
$ grep CONFIG arch/cris/Configure.help |wc
75 138 2337
$ grep CONFIG Documentation/Configure.help |wc
1486 1640 30135it's not entiraly correct since the CONFIG_BLUETOOTH help is in the arch/cris directory and that should probably be in Documentation/ or in the OpenBT package and merged from there. The file also contains the # LocalWords: rows from the original Configure.help.
But the ETRAX/CRIS config is 3-5% of the total config.
Having the help close to the config sounds like a good idea from a maintenance point of view.
Quoted 36 lines
I would prefer to have config.in and help file togheter. But in the
discussion in kbuild list, it come that is is better to merge all configuration in one file and the strings in an other (and thus
not to merge Configure.help to not heve a very huge file).What are the advanteget to split the Configure.help?
Quoted 13 lines
The help system first checks the file in
arch/$ARCHand if the help is not present there it checks the one inDocumentation/Quoted 6 lines
If you should provide a special help on a specific ARCH you could modify the symbols: instead of
: bool 'std IPC support'CONFIG_IPC
you can do:
: bool 'arch specific IPC help'CONFIG_IPC_STRANGE_ARCH:define_boolCONFIG_IPCCONFIG_IPC_STRANGE_ARCHQuoted 7 lines
Don't know if you missunderstood me or if I missunderstand you here.
The typical use for the arch specific help file would only cover the arch specific CONFIG options (although it could "override" the general help text inDocumentation/Configure.helpwith an arch specific one, but if you do that I guess you're doing something wrong)I think I missunderstood you. But this was the big issue for splitting Configure.help. (Thus if an developer should use at arch specific help, he should use this method)
Quoted 1 line
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
ESR CML2 have the defualt path for Configure.help build in the rules files, but it can be overriden by command options to use an other Configure.help (the format do not change).
I want to be able to use two help files.
I think it is not a big issue. In
Makefilewe can
: cat Conf.help.1 Conf.help2 > .Conf.help
Sounds better than dealing with two different help files in the config system.
Is there an ETA when ESR CML2 will be in the official kernel? (I guess I should catch up on what it will provide instead of
wasting peoples time...)
Would adding support for merging help files in the current config system be accepted in the meanwhile?
E.g. Configure, Menuconfig and header.tk is changed to use Documentation/Configure.help.generated
and the top Makefile does
cat $(HELPFILES) >Documentation/Configure.help.generated 2>/dev/null for oldconfig, config, menuconfig and xconfig targets? And HELPFILES is set to:
HELPFILES = arch/$(ARCH)/Configure.help Documentation/Configure.help
External patches that add functionality could easaly add HELPFILES += some new help files
rows to get the help as well.
Quoted 1 line
giacomo
/Johan
Kernel 2.4.3 compile error - why ??
Hi,
I try to compile kernel downloaded from
ftp.kernel.org.
I have all programs that this kernel require.
But I can't compile kernel :(
Ooops, can't compile kernel modules:
[...]
make[3]: Opuszczam katalog `/users/cieciwa/rpm/BUILD/linux/drivers/media/radio' make -C video modules
make[3]: Wchodzę katalog `/users/cieciwa/rpm/BUILD/linux/drivers/media/video' ld -m elf_i386 -r -o bttv.o bttv-driver.o bttv-cards.o bttv-if.o ld -m elf_i386 -r -o zoran.o zr36120.o zr36120_i2c.o zr36120_mem.o
gcc -D__KERNEL__ -I/users/cieciwa/rpm/BUILD/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -c -o buz.o buz.cbuz.c: In function `v4l_fbuffer_alloc':
buz.c:188: `KMALLOC_MAXSIZE' undeclared (first use in this function) buz.c:188: (Each undeclared identifier is reported only once buz.c:188: for each function it appears in.)buz.c: In function `jpg_fbuffer_alloc':
buz.c:262: KMALLOC_MAXSIZE' undeclared (first use in this function) buz.c:256: warning: alloc_contig' might be used uninitialized in this function buz.c: In function `jpg_fbuffer_free':
buz.c:322: KMALLOC_MAXSIZE' undeclared (first use in this function) buz.c:316: warning: alloc_contig' might be used uninitialized in this function buz.c: In function `zoran_ioctl':
buz.c:2837: `KMALLOC_MAXSIZE' undeclared (first use in this function) make[3]: *** [buz.o] Błąd 1
make[3]: Opuszczam katalog `/users/cieciwa/rpm/BUILD/linux/drivers/media/video' make[2]: *** [_modsubdir_video] Błąd 2
make[2]: Opuszczam katalog `/users/cieciwa/rpm/BUILD/linux/drivers/media' make[1]: *** [_modsubdir_media] Błąd 2
make[1]: Opuszczam katalog `/users/cieciwa/rpm/BUILD/linux/drivers'
make: *** [_mod_drivers] Błąd 2
What's wrong ??
Thanx.
Sas.P.S.
Sorry for my "language".
Signature · 2 lines
{Wojciech 'Sas' Cieciwa} {Member of PLD Team }
{e-mail: [email protected], http://www2.zarz.agh.edu.pl/~cieciwa}Quoted 19 lines · Johan Adolfsson
Quoted 8 lines
- IIRC there is only few ARCH specific configuration, thus we don't
reduce the size of che Configure.help
Note that thearch/config.inhave to much configuration item (but they repeat in (nearly) allarch/config.infiles, thus
you
should count only the really arch specific item.Here are some results:
$ wc arch/cris/Configure.help 621 4424 28373 arch/cris/Configure.help $ wc Documentation/Configure.help 17480 121037 773694 Documentation/Configure.help $ grep CONFIG arch/cris/Configure.help |wc 75 138 2337 $ grep CONFIG Documentation/Configure.help |wc 1486 1640 30135
Quoted 7 lines
it's not entiraly correct since the
CONFIG_BLUETOOTHhelp is in thearch/crisdirectory and that should probably be inDocumentation/or in the OpenBT package and merged from there. The file also contains the # LocalWords: rows from the original Configure.help.But the ETRAX/CRIS config is 3-5% of the total config.
This seem too much. If all arch have a so big CONFIG space, I think that your idea can do some improvement.
But: user don't see the difference. Do you think that developers
would like your proposal? (If arch maintainers agree, you can try to publish your patch)
Quoted 3 lines
Having the help close to the config sounds like a good idea from a maintenance point of view.
But in 2.5.x the config.in are centralized, thus also Configure.help sould be centralized.
And in this case I think that a big file hurts nobody.
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
Quoted 3 lines
ESR CML2 have the defualt path for Configure.help build in the rules files, but it can be overriden by command options to use an other Configure.help (the format do not change).
I want to be able to use two help files.
Quoted 8 lines
Quoted 2 lines
I think it is not a big issue. In
Makefilewe can
: cat Conf.help.1 Conf.help2 > .Conf.helpSounds better than dealing with two different help files in the config system.
Is there an ETA when ESR CML2 will be in the official kernel? (I guess I should catch up on what it will provide instead of
wasting peoples time...)
In 2.5.2 kernel. What We don't know is when 2.5.2 will be released!
Quoted 3 lines
Would adding support for merging help files in the current config system be accepted in the meanwhile?
In 2.4: No. Distribution expect a stable interface. In 2.5 will be the new CML2.
Again if arch maintainer agree with your proposal, you can change
the CML2. Not so difficult (and you change only in one place for all interfaces (olconfig/config/menuconfig/xconfig)
Quoted 11 lines
E.g. Configure, Menuconfig and header.tk is changed to use
Documentation/Configure.help.generated
and the topMakefiledoes
cat $(HELPFILES) >Documentation/Configure.help.generated 2>/dev/null for oldconfig, config, menuconfig and xconfig targets? And HELPFILES is set to:
HELPFILES = arch/$(ARCH)/Configure.helpDocumentation/Configure.helpExternal patches that add functionality could easaly add HELPFILES += some new help files
rows to get the help as well.
This change is too big for 2.4 kernel.
giacomo
"Giacomo Catenazzi wrote:"
Quoted 8 lines
Quoted 3 lines · Johan Adolfsson
Having the help close to the config sounds like a good idea from a maintenance point of view.
But in 2.5.x the config.in are centralized, thus also Configure.help sould be centralized.
And in this case I think that a big file hurts nobody.
What about common config options (like CONFIG_PCI, CONFIG_BINFMT_ELF, CONFIG_SMP, CONFIG_SERIAL), which have Configure.help entries wtitten in PC-centric style?
What is info about ISA/EISA bus for sparc users for? Why no info about SBUS there?
What is COM3 for Amiga user?
How can alpha user compile kernel for Pentium?
What is the difference between ELF and A.OUT for architectures that do not support a.out at all?
IMO some, even very standard, options may need different explanations for different architectures.
Maybe some kind of architecture-specyfic #include in Configure.help entries?
Just my 0.03 PLZ
Andrzej
Quoted 22 lines · Andrzej Krzysztofowicz
"Giacomo Catenazzi wrote:"
Quoted 8 lines
Quoted 3 lines · Johan Adolfsson
Having the help close to the config sounds like a good idea from a maintenance point of view.
But in 2.5.x the config.in are centralized, thus also Configure.help sould be centralized.
And in this case I think that a big file hurts nobody.What about common config options (like
CONFIG_PCI,CONFIG_BINFMT_ELF,CONFIG_SMP,CONFIG_SERIAL), which have Configure.help entries wtitten in PC-centric style?What is info about ISA/EISA bus for sparc users for? Why no info about SBUS there?
What is COM3 for Amiga user?
How can alpha user compile kernel for Pentium?
What is the difference between ELF and A.OUT for architectures that do not support a.out at all?
Quoted 4 lines
IMO some, even very standard, options may need different explanations for different architectures.
Maybe some kind of architecture-specyfic #include in Configure.help entries?
Two possibilities: With std configuration language change:
: bool 'std IPC support' CONFIG_IPC
into
: bool 'arch specific IPC help' CONFIG_IPC_STRANGE_ARCH : define_bool CONFIG_IPC CONFIG_IPC_STRANGE_ARCH
This is "clean" and is allowed by CML1 (and in CML2 with a similar change).
Or we can use the method of Johan.
But if we move some option in i386/Configure.help, users of other arch
instead of being little confused, their will see no help -> worse!
Maybe before to make changes, all developers should read the documentation
and update/change it in a non i386 centric view.
BTW some other arch will use i386 devices, thus or we duplicate (and
that one of the copy will be old) some entry of we must make configure.help
i386 centric (and provide other help for other arch). But SPARC and SPARC64
will use some configuration (different to i386), thus we should duplicate
half configuration in SPARC.. ?
giacomo
Re: Arch specific/multiple Configure.help files? [PATCH included]
In reply to a message not in the archive----- Original Message -----
From: Giacomo Catenazzi <[email protected]>
To: Johan Adolfsson <[email protected]>
Cc: <[email protected]>
Sent: Friday, April 06, 2001 11:39
Subject: Re: Arch specific/multiple Configure.help files?
Quoted 26 lines
Quoted 25 lines · Johan Adolfsson
Quoted 8 lines
- IIRC there is only few ARCH specific configuration, thus we don't
reduce the size of che Configure.help
Note that thearch/config.inhave to much configuration item (but they repeat in (nearly) allarch/config.infiles, thus
you
should count only the really arch specific item.Here are some results:
$ wc arch/cris/Configure.help 621 4424 28373 arch/cris/Configure.help $ wc Documentation/Configure.help 17480 121037 773694 Documentation/Configure.help $ grep CONFIG arch/cris/Configure.help |wc 75 138 2337 $ grep CONFIG Documentation/Configure.help |wc 1486 1640 30135it's not entiraly correct since the
CONFIG_BLUETOOTHhelp is in thearch/crisdirectory and that should probably be inDocumentation/or in the OpenBT package and merged from there. The file also contains the # LocalWords: rows from the original Configure.help.
Quoted 4 lines
Quoted 1 line
But the ETRAX/CRIS config is 3-5% of the total config.
This seem too much. If all arch have a so big CONFIG space, I think that your idea can do some improvement.
The file contains some stuff we used in the 2.0 uC-linux version that we now implement using the netfilter and an application (6 options), and the bluetooth stuff has 10 options, but the rest is more or less hardware (ETRAX) specific stuff.
Quoted 4 lines
But: user don't see the difference. Do you think that developers
would like your proposal? (If arch maintainers agree, you can try to publish your patch)
As a developer I would ;-) (although I'm not the real maintainer) Using this feature is not mandatory, but for SOC solutions that are not PC based, I think it could be helpful.
Quoted 14 lines
Quoted 2 lines
Having the help close to the config sounds like a good idea from a maintenance point of view.
But in 2.5.x the config.in are centralized, thus also Configure.help sould be centralized.
And in this case I think that a big file hurts nobody.Quoted 6 lines
Sounds better than dealing with two different help files in the config system.
Is there an ETA when ESR CML2 will be in the official kernel? (I guess I should catch up on what it will provide instead of
wasting peoples time...)
Quoted 8 lines
In 2.5.2 kernel. What We don't know is when 2.5.2 will be released!
Quoted 3 lines
Would adding support for merging help files in the current config system be accepted in the meanwhile?
In 2.4: No. Distribution expect a stable interface.
I'm not sure about the definition of a "stable interface", but this will not really change the interface at all.
Quoted 14 lines
In 2.5 will be the new CML2.
Again if arch maintainer agree with your proposal, you can change
the CML2. Not so difficult (and you change only in one place for all interfaces (olconfig/config/menuconfig/xconfig)Quoted 8 lines
E.g. Configure, Menuconfig and header.tk is changed to use
Documentation/Configure.help.generated
and the topMakefiledoes
cat $(HELPFILES) >Documentation/Configure.help.generated 2>/dev/null for oldconfig, config, menuconfig and xconfig targets? And HELPFILES is set to:
HELPFILES = arch/$(ARCH)/Configure.helpDocumentation/Configure.help
Quoted 5 lines
Quoted 3 lines
External patches that add functionality could easaly add HELPFILES += some new help files
rows to get the help as well.This change is too big for 2.4 kernel.
It doesnt look that big to mee, so here it is for everyones consideration (the mailprogram probably screws up tabs etc. but you get the idea, I apologise if posting patches like this is the wrong way)
The normal user/developer shouldn't even notice the difference, the patch shouldn't break anything, just make it possible to use multiple help files.
linux/Makefile: (linenumber probably a bit off)
@@ -40,6 +44,10 @@ MODFLAGS = -DMODULE
CFLAGS_KERNEL =
PERL = perl
+# Helpfiles used in the config system
+# (merged to Documentation/Configure.help.generated)
+HELPFILES = arch/$(ARCH)/Configure.help Documentation/Configure.help
+
export VERSION PATCHLEVEL SUBLEVEL EXTRAVERSION KERNELRELEASE ARCH \
CONFIG_SHELL TOPDIR HPATH HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD CC \
CPP AR NM STRIP OBJCOPY OBJDUMP MAKE MAKEFILES GENKSYMS MODFLAGS PERL
@@ -260,19 +270,22 @@ symlinks:
@if [ ! -d include/linux/modules ]; then \
mkdir include/linux/modules; \
fi
+
+helpfiles:
+ -cat $(HELPFILES) >Documentation/Configure.help.generated 2>/dev/null
-oldconfig: symlinks
+oldconfig: symlinks helpfiles
$(CONFIG_SHELL) scripts/Configure -d arch/$(ARCH)/config.in
-xconfig: symlinks
+xconfig: symlinks helpfiles
$(MAKE) -C scripts kconfig.tk
wish -f scripts/kconfig.tk
-menuconfig: include/linux/version.h symlinks +menuconfig: include/linux/version.h symlinks helpfiles
$(MAKE) -C scripts/lxdialog all
$(CONFIG_SHELL) scripts/Menuconfig arch/$(ARCH)/config.in
-config: symlinks
+config: symlinks helpfiles
$(CONFIG_SHELL) scripts/Configure arch/$(ARCH)/config.in
include/config/MARKER: scripts/split-include include/linux/autoconf.h
RCS file: /n/cvsroot/os/linux/scripts/Configure,v
retrieving revision 1.1.1.2
Configure 2001/04/06 09:57:44 renamed from Configure 2001/01/10 13:28:58 1.1.1.2 +3 -0
@@ -48,6 +48,10 @@ # # 24 January 1999, Michael Elizabeth Chastain, <[email protected]> # - Improve the exit message (Jeff Ronne). +# +# 6 April 2000, Johan Adolfsson <[email protected]> +# - Use Documentation/Configure.help.generated to support merging help
files
+
#
# Make sure we're really running bash.
@@ -81,7 +85,7 @@ function endmenu () {
# help variable
#
function help () {
- if [ -f Documentation/Configure.help ]
+ if [ -f Documentation/Configure.help.generated ]
then
#first escape regexp special characters in the argument:
var=$(echo "$1"|sed 's/[][\/.^$*]/\\&/g')
@@ -93,7 +97,7 @@ ${var}:\\
/^#/b
/^[^ ]/q
p
- }" Documentation/Configure.help)
+ }" Documentation/Configure.help.generated)
if [ -z "$text" ]
then
echo; echo " Sorry, no help available for this option yet.";echo
RCS file: /n/cvsroot/os/linux/scripts/Menuconfig,v retrieving revision 1.1.1.2
Menuconfig 2001/04/06 09:58:40 renamed from Menuconfig 2001/01/10 13:28:58 1.1.1.2 +0 -0
@@ -74,6 +74,8 @@ # - Implemented new functions: define_tristate(), define_int(),
define_hex(),
# define_string(), dep_bool().
#
+# 6 April 2000, Johan Adolfsson <[email protected]> +# - Use Documentation/Configure.help.generated to support merging help files
#
@@ -364,7 +366,7 @@ function choice () {
# Configure script.
#
function extract_help () {
- if [ -f Documentation/Configure.help ]
+ if [ -f Documentation/Configure.help.generated ] then
#first escape regexp special characters in the argument:
var=$(echo "$1"|sed 's/[][\/.^$*]/\\&/g')
@@ -377,7 +379,7 @@ ${var}:\\
/^[^ ]/q
s/^ //
p- }" Documentation/Configure.help)
+ }" Documentation/Configure.help.generated)
if [ -z "$text" ]
thenRCS file: /n/cvsroot/os/linux/scripts/header.tk,v
retrieving revision 1.1.1.1
header.tk 2001/04/06 09:59:59 renamed from header.tk 2000/07/10 15:30:13 1.1.1.1 +3 -0
@@ -15,6 +15,9 @@ # # 24 January 1999, Michael Elizabeth Chastain, <[email protected]> # - Improve the exit message (Jeff Ronne). +# +# 6 April 2000, Johan Adolfsson <[email protected]> +# - Use Documentation/Configure.help.generated to support merging help
files
#
# This is a handy replacement for ".widget cget" that requires neither tk4
@@ -453,7 +456,7 @@ proc dohelp {w var parent} {
set found 0
set lineno 0
- if { [file readable Documentation/Configure.help] == 1} then {
+ if { [file readable Documentation/Configure.help.generated] == 1} then { set filefound 1
# First escape sed regexp special characters in var:
set var [exec echo "$var" | sed s/\[\]\[\/.^$*\]/\\\\&/g]
@@ -468,7 +471,7 @@ ${var}:\\
s/^ //
p
}
- " Documentation/Configure.help]
+ " Documentation/Configure.help.generated]
set found [expr [string length "$message"] > 0]
}
/Johan
Re: Arch specific/multiple Configure.help files? [PATCH included]
In reply to a message not in the archiveQuoted 24 lines · Johan Adolfsson
Quoted 2 lines
This change is too big for 2.4 kernel.
It doesnt look that big to mee, so here it is for everyones consideration (the mailprogram probably screws up tabs etc. but you get the idea, I apologise if posting patches like this is the wrong way)
The normal user/developer shouldn't even notice the difference, the patch shouldn't break anything, just make it possible to use multiple help files.
linux/Makefile: (linenumber probably a bit off)
(quoted diff) +4
-0@@ -40,6 +44,10 @@ MODFLAGS = -DMODULE CFLAGS_KERNEL = PERL = perl +# Helpfiles used in the config system +# (merged to Documentation/Configure.help.generated) +HELPFILES = arch/$(ARCH)/Configure.help Documentation/Configure.help + export VERSION PATCHLEVEL SUBLEVEL EXTRAVERSION KERNELRELEASE ARCH \ CONFIG_SHELL TOPDIR HPATH HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD CC \ CPP AR NM STRIP OBJCOPY OBJDUMP MAKE MAKEFILES GENKSYMS MODFLAGS PERL
Review symlinks: · line 277
Quoted 9 lines
(quoted diff) +4
-1@@ -260,19 +270,22 @@ symlinks: @if [ ! -d include/linux/modules ]; then \ mkdir include/linux/modules; \ fi + +helpfiles: + -cat $(HELPFILES) >Documentation/Configure.help.generated 2>/dev/null -oldconfig: symlinks +oldconfig: symlinks helpfiles
No!Documentation/Configure.help.generated: $(HELPFILES)
-cat $(HELPFILES) >Documentation/Configure.help.generated
2>/dev/null
oldconfig: symlinks Documentation/Configure.help.generated
...
Really you should include the ARCH/COnfigure.help in $(HELPFILES) only
if it exists (else make will complain)
Quoted 6 lines
(quoted diff) +1
-1$(CONFIG_SHELL) scripts/Configure -d arch/$(ARCH)/config.in -xconfig: symlinks +xconfig: symlinks helpfiles $(MAKE) -C scripts kconfig.tk wish -f scripts/kconfig.tk
Review symlinks: · line 290
Quoted 10 lines
(quoted diff) +2
-2-menuconfig: include/linux/version.h symlinks +menuconfig: include/linux/version.h symlinks helpfiles $(MAKE) -C scripts/lxdialog all $(CONFIG_SHELL) scripts/Menuconfig arch/$(ARCH)/config.in -config: symlinks +config: symlinks helpfiles $(CONFIG_SHELL) scripts/Configure arch/$(ARCH)/config.in
ditto.
Configure 2001/04/06 09:57:44
Quoted 7 lines
(quoted diff) +0
-0include/config/MARKER: scripts/split-include include/linux/autoconf.hRCS file: /n/cvsroot/os/linux/scripts/Configure,v
retrieving revision 1.1.1.2
diff -u -p -r1.1.1.2 ConfigureConfigure 2001/04/06 09:57:44 renamed from Configure 2001/01/10 13:28:58 1.1.1.2 +0
-0
OK!
Re: Arch specific/multiple Configure.help files? [PATCH included]
In reply to a message not in the archive----- Original Message -----
From: Giacomo Catenazzi <[email protected]>
To: Johan Adolfsson <[email protected]>
Cc: <[email protected]>
Sent: Friday, April 06, 2001 13:34
Subject: Re: Arch specific/multiple Configure.help files? [PATCH included]
Quoted 5 lines
Quoted 4 lines · Johan Adolfsson
Quoted 2 lines
This change is too big for 2.4 kernel.
It doesnt look that big to mee, so here it is for everyones
consideration
Quoted 7 lines
Quoted 7 lines
(the mailprogram probably screws up tabs etc. but you get the idea, I apologise if posting patches like this is the wrong way)
The normal user/developer shouldn't even notice the difference, the patch shouldn't break anything, just make it possible to use multiple help files.
Quoted 8 lines
Review MODFLAGS = -DMODULE · line 49
Quoted 8 lines
linux/Makefile: (linenumber probably a bit off)
(quoted diff) +3
-0@@ -40,6 +44,10 @@ MODFLAGS = -DMODULE CFLAGS_KERNEL = PERL = perl +# Helpfiles used in the config system +# (merged to Documentation/Configure.help.generated) +HELPFILES = arch/$(ARCH)/Configure.help
Documentation/Configure.help
Quoted 20 lines
Quoted 5 lines
(quoted diff) +1
-0+ export VERSION PATCHLEVEL SUBLEVEL EXTRAVERSION KERNELRELEASE ARCH \ CONFIG_SHELL TOPDIR HPATH HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD CC \ CPP AR NM STRIP OBJCOPY OBJDUMP MAKE MAKEFILES GENKSYMS MODFLAGS PERLReview symlinks: · line 277
Quoted 9 lines
(quoted diff) +4
-1@@ -260,19 +270,22 @@ symlinks: @if [ ! -d include/linux/modules ]; then \ mkdir include/linux/modules; \ fi + +helpfiles: + -cat $(HELPFILES) >Documentation/Configure.help.generated 2>/dev/null -oldconfig: symlinks +oldconfig: symlinks helpfilesNo!
Documentation/Configure.help.generated: $(HELPFILES) -cat $(HELPFILES) >Documentation/Configure.help.generated 2>/dev/null
Quoted 6 lines
oldconfig: symlinks
Documentation/Configure.help.generated
...Really you should include the ARCH/COnfigure.help in $(HELPFILES) only
if it exists (else make will complain)
That's why I had the -cat and the 2>/dev/null
and not dependencies to them :-)
I'm not a Makefile wizard but the following seems to work, but it might skip the generation of Configure.help.generated if you change ARCH and happen to have an old help file in the arch directory, so I'm not so sure it really is a good idea. It's safer to generate the file everytime, it doesn't cost much in time compared to the gerenetion of the configure scripts.
+ # Helpfiles used in the config system
+ # (merged to Documentation/Configure.help.generated)
+ # Add arch specific help if it exists:
+ ifeq (arch/${ARCH}/Configure.help,$(wildcard arch/${ARCH}/Configure.help))
+ HELPFILES = arch/$(ARCH)/Configure.help
+ else
+ HELPFILES =
+ endif
+ # Always use good old Documentation/Configure.help:
+ HELPFILES += Documentation/Configure.help
+ Documentation/Configure.help.generated: $(HELPFILES)
+ cat $(HELPFILES) >Documentation/Configure.help.generated
Quoted 21 lines
Quoted 6 lines
(quoted diff) +1
-1$(CONFIG_SHELL) scripts/Configure -d arch/$(ARCH)/config.in -xconfig: symlinks +xconfig: symlinks helpfiles $(MAKE) -C scripts kconfig.tk wish -f scripts/kconfig.tkReview symlinks: · line 290
Quoted 10 lines
(quoted diff) +2
-2-menuconfig: include/linux/version.h symlinks +menuconfig: include/linux/version.h symlinks helpfiles $(MAKE) -C scripts/lxdialog all $(CONFIG_SHELL) scripts/Menuconfig arch/$(ARCH)/config.in -config: symlinks +config: symlinks helpfiles $(CONFIG_SHELL) scripts/Configure arch/$(ARCH)/config.inditto.
Quoted 2 lines
(quoted diff) +0
-0include/config/MARKER: scripts/split-include include/linux/autoconf.h
Quoted 7 lines
Configure 2001/04/06 09:57:44
Quoted 5 lines
RCS file: /n/cvsroot/os/linux/scripts/Configure,v
retrieving revision 1.1.1.2
diff -u -p -r1.1.1.2 ConfigureConfigure 2001/04/06 09:57:44 renamed from Configure 2001/01/10 13:28:58 1.1.1.2 +0
-0OK!
Does this meen you think this suggestion is ok?
/Johan