public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Johan Adolfsson" <johan.adolfsson@axis.com>
To: <cate@debian.org>, <johan.adolfsson@axis.com>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: Arch specific/multiple Configure.help files?
Date: Fri, 6 Apr 2001 11:07:14 +0200	[thread overview]
Message-ID: <19da01c0be78$f9106c90$0a070d0a@axis.se> (raw)
In-Reply-To: <fa.ggqkpgv.9g0c0b@ifi.uio.no> <fa.k6fq96v.nhaq06@ifi.uio.no> <3ACD68FF.637D8958@math.ethz.ch> <018001c0be69$90dcb200$9db270d5@homeip.net> <3ACD73E0.2B1DFF6F@math.ethz.ch>


----- Original Message ----- 
From: Giacomo Catenazzi <cate@math.ethz.ch>
To: <johana@axis.com>
Cc: <linux-kernel@vger.kernel.org>
Sent: Friday, April 06, 2001 09:44
Subject: Re: Arch specific/multiple Configure.help files?


> johan.adolfsson@axis.com wrote:
> > 
> > > 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 or
> > Documentation/Configure.help
> 
> 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:-)

> - 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.

> - 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.

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

it'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.

> 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?
> 
> > 
> > The help system first checks the file in arch/$ARCH and if
> > the help is not present there it checks the one in Documentation/
> > 
> 
> 
> > > 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
> > 
> > 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)
> 
> 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)
> 
> > 
> > > 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

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.

> giacomo

/Johan



  reply	other threads:[~2001-04-06  9:11 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fa.ggqkpgv.9g0c0b@ifi.uio.no>
     [not found] ` <fa.k6fq96v.nhaq06@ifi.uio.no>
2001-04-06  6:58   ` Arch specific/multiple Configure.help files? Giacomo Catenazzi
2001-04-06  7:16     ` johan.adolfsson
2001-04-06  7:44       ` Giacomo Catenazzi
2001-04-06  9:07         ` Johan Adolfsson [this message]
2001-04-06  8:21           ` Kernel 2.4.3 compile error - why ?? Wojciech "Sas" Cieciwa
2001-04-06  9:39           ` Arch specific/multiple Configure.help files? Giacomo Catenazzi
2001-04-06 10:19             ` Arch specific/multiple Configure.help files? [PATCH included] Johan Adolfsson
2001-04-06 10:35             ` Arch specific/multiple Configure.help files? Andrzej Krzysztofowicz
2001-04-06 11:45               ` Giacomo Catenazzi
2001-04-06 11:34           ` Arch specific/multiple Configure.help files? [PATCH included] Giacomo Catenazzi
     [not found]           ` <3ACD8ECC.F2518B90@math.ethz.c <3ACDA9CB.583241B6@math.ethz.ch>
2001-04-06 12:40             ` Johan Adolfsson
2001-03-26 22:33 CML2 0.9.7 is available Eric S. Raymond
2001-04-05 17:28 ` Arch specific/multiple Configure.help files? Johan Adolfsson
2001-04-05 19:41   ` Erik Mouw
2001-04-05 21:56     ` Rogier Wolff
2001-04-05 22:03       ` Rogier Wolff
2001-04-06  5:40       ` johan.adolfsson

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to='19da01c0be78$f9106c90$0a070d0a@axis.se' \
    --to=johan.adolfsson@axis.com \
    --cc=cate@debian.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

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

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