Hi,
On Mon, 1 Oct 2007, Oleg Verych wrote:
> Today's kconfig was proposed and accepted in a very unpleasant
> circumstances, has very poor design, development and no working
> alternative (for 5+ years now).
If you want to make such statements, you have to offer a little more than
the hot air y
Hi,
On Fri, 31 Aug 2007, Jan Beulich wrote:
> Doing a few more experiments with choices, I find that int, hex, and string
> don't seem to work at all here. It would seem to me that these all could be
> useful, but clearly would require some changes even in the grammar in order
> to get there.
We
y one choice. The patch below avoids the setting of the value here.
bye, Roman
Avoid setting the value if the symbol doesn't need to be changed or can't
be changed. Later choices may change the dependencies and thus the
possible input range.
Signed-off-by: Roman Zippel <[EMAIL
Hi,
On Wed, 29 Aug 2007, Jan Beulich wrote:
> Roman,
>
> while I realize that it might not be intended to be used in this way (though
> nothing
> explicitly says it either way), I'm trying to understand why this (much
> simplified)
> input
>
> config MODULES
> bool "Enable loadable modu
Hi,
On Tue, 21 Aug 2007, Andres Salomon wrote:
> > I would really like to avoid another input mode.
> > I think it be better to implement this as a combination of "-s -D
> > " and the silent mode is adjusted to read another config instead
> > of .config if defconfig_file is set.
> >
>
> As wo
Hi,
On Mon, 20 Aug 2007, Andres Salomon wrote:
> AFAICT, there is nothing similar when using *_defconfig; one must copy
> a .config manually, and then run silentoldconfig. Simply running the
> associated _defconfig will quietly update the config (which may silently
> drop config options). This
Hi,
On Wed, 16 May 2007, Al Viro wrote:
> On Tue, May 15, 2007 at 08:36:20PM +0100, Al Viro wrote:
> >
> > stuff that does select USB should depend on USB_ARCH_HAS_HCD, or we'll
> > end up with unbuildable configs.
>
> BTW, this kind of situation happens often enough, so how about doing
> the f
Hi,
On Fri, 16 Feb 2007, Blaisorblade wrote:
> On Friday 16 February 2007 20:12, Roman Zippel wrote:
> > Hi,
> >
> > On Fri, 16 Feb 2007, Blaisorblade wrote:
> > > However, more important, if I remove STACKTRACE_SUPPORT, or if I make
> > > it 'defa
Hi,
On Fri, 16 Feb 2007, Blaisorblade wrote:
> However, more important, if I remove STACKTRACE_SUPPORT, or if I make
> it 'default n', FAULT_INJECTION can still be enabled, even if it selects
> STACKTRACE which has a failed dependency (tested on UML). Which is a Kconfig
> bug - if A selects B
Hi,
On Thursday 28 December 2006 22:05, Adrian Bunk wrote:
> How to add some warning prints?
Simple, see the attached patch.
> And what's the problem with changing the generated files?
> There doesn't seem to be much activity in this area, and the noise of
> changing the generated files doesn't
Hi,
On Mon, 18 Dec 2006, Adrian Bunk wrote:
> On Mon, Dec 18, 2006 at 11:41:59AM -0500, Robert P. J. Day wrote:
> >
> > Remove the note in the documentation that suggests people can use
> > "requires" for dependencies in Kconfig files.
> >...
>
> Considering that noone uses it, what about the
Hi,
On Thu, 28 Sep 2006, karsten wiese wrote:
> enable/disable the qt- and gtk-gui configurator's
> "save" toolbar-button/menu-entry.
>
> The qt-configurator asks the user, if he want's to save the changed
> .config if sym_change_count!=0.
Ok, then please split the patch a bit differently.
1.
Hi,
On Sun, 24 Sep 2006, Karsten Wiese wrote:
> Make sym_change_count static, implement
> void sym_change_count_set(int)
> and
> int sym_change_count(void)
> to set or get its value;
> sym_change_count is only changed by void sym_change_count_set(int).
> the latter can call a callbac
Hi,
On Mon, 12 Dec 2005, Petr Baudis wrote:
> In practice, this means that drawing on the screen is done with _MUCH_
> less overhead now, the screen updates are better optimalized as ncurses
> won't get reset everytime you display something, that also implies that
> the ugly screen flickering is
Hi,
On Thu, 20 Oct 2005, David Gibson wrote:
> When doing its recursive dependency check, scripts/kconfig/conf uses
> the flag SYMBOL_CHECK_DONE to avoid rechecking a symbol it has already
> checked. However, that flag is only set at the top level, so if a
> symbol is first encountered as a depe
Hi,
On Sun, 31 Jul 2005, Sam Ravnborg wrote:
> In a couple of cases I have had the need to include a Kconfig file only
> if present.
> The current 'source' directive works as one would expect. It bails out
> if the file is missing.
I don't really like it, it's an open invitation to abuse.
I'd ra
Hi,
On Mon, 4 Jul 2005, Kurt Wall wrote:
> --- a/scripts/lxdialog/Makefile 2005-07-04 09:54:44.0 -0400
> +++ b/scripts/lxdialog/Makefile 2005-07-04 11:50:00.0 -0400
> @@ -35,8 +35,11 @@
> echo -e "\007" ;\
> echo ">> Unable to find the Ncurs
veral string functions so it couldn't be
> signed.
> - strip() uses strlen() so same thing there.
>
> Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>
Acked-by: Roman Zippel <[EMAIL PROTECTED]>
Looks good, thanks.
bye, Roman
-
Hi,
On Wed, 22 Jun 2005, Pierre Ossman wrote:
> -void define_config(const char * name, int len)
> +void define_config(const void * name, int len)
Could you try to drop the remaining "signed" instead of this?
bye, Roman
---
SF.Net email is s
Hi,
On Tue, 21 Jun 2005, Pierre Ossman wrote:
> GCC 4 checks the signedness of pointer casts and generates a whole bunch
> of warnings for code in scripts/ (which makes heavy use of signed char
> strings).
>
> This patch adds explicit casts.
Just adding explicit all over the place is really the
Hi,
On Tue, 21 Jun 2005, Pierre Ossman wrote:
> Is there some easy way to check the file history? Downloading a couple
> of old kernels just for one file is a bit of a hassle. And I don't run
> bk so I can't access that repository (is it even still present after
> Linus' move?).
http://linux.bkb
Hi,
On Tue, 21 Jun 2005, Pierre Ossman wrote:
> Should I extract the changes for bkbits and make a reversed patch?
No, go through the warnings, analyze each one and choose an appropriate
solution. You might want to keep notes, which you can post with the
changelogs, so one can reproduce, why a
Hi,
On Tue, 21 Jun 2005, Pierre Ossman wrote:
> A (somewhat unclean) solution is to make the type change based on the
> platform. Are there any defines present to test if we're in a Solaris
> environment? I don't have access to any Solaris machines myself so I
> can't really test.
Just ignore it
Hi,
On Tue, 31 May 2005, Blaisorblade wrote:
> I can regenerate it only with bison 2.0, since that's what I have installed.
> So if you don't want it to be regenerated, you cannot accept my patch. I
> proposed sending two patches to avoid mixing the bison changes with this
> patch changes, tha
Hi,
On Tue, 31 May 2005, Adrian Bunk wrote:
> there's still the point that it's currently used inconsistently.
Why is it so important to fix this "inconsistency"?
Why is it so difficult to accept that both are valid options?
bye, Roman
---
T
Hi,
On Sun, 29 May 2005 [EMAIL PROTECTED] wrote:
> If you want, I'll do one patch update the included version to 2.0 Bison (which
> uses an updated skeleton) and then, separately, a patch updating
> zconf.tab.c_shipped to reflect the updated zconf.y.
I'd prefer to patch the changes into zconf.ta
Hi,
On Tue, 31 May 2005, Adrian Bunk wrote:
> The main reason for this patch (quoting Jesper) is:
> Consistency. out of ~4000 help entries in 134 Kconfig files, 747 of
> those entries use "---help---" as the keyword, the rest use just "help".
> So the users of "---help---" are clearly a m
Hi,
On Tue, 3 May 2005, Adrian Bunk wrote:
> > So why exactly has to be removed? Is it ugly? Does it make Kconfig worse?
>
> The ugly thing is that there are currently two different ways to express
> the same thing. It only causes confusion for people who think those
> different syntaxes had a
Hi,
On Tue, 3 May 2005, Adrian Bunk wrote:
> The separator used for the help is to indent help texts by two
> additional spaces.
Yes, that's an additional indicator.
> IMHO, Kconfig files are quite readable due to this indentation even
> though only a minority of the entries was using "---hel
Hi,
On Tue, 3 May 2005, Adrian Bunk wrote:
> This patch is the majority of a patch by Jesper Juhl.
>
> This patch renames all instances of "---help---" to simply "help" in all
> of the Kconfig files.
>
> The main reason for this patch (quoting Jesper) is:
>
> Consistency. out of ~4000 help en
Hi,
On Tue, 22 Mar 2005 [EMAIL PROTECTED] wrote:
> Replace a menu_add_prop mimicking menu_add_prompt with the latter.
>
> Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
> ---
>
> linux-2.6.11-paolo/scripts/kconfig/zconf.y |2 +-
> 1 files changed, 1 insertion(+), 1 delet
Hi,
On Tue, 22 Mar 2005, Blaisorblade wrote:
> I've verified multiple times that if we have a situation like this
>
> bool A
> depends on TRUE
> help
> Bla bla1
>
> and
>
> bool A
> depends on FALSE
> help
> Bla bla2
>
> even if the first option is the displayed one, the help text used is
Hi,
On Fri, 8 Oct 2004, Robert P. J. Day wrote:
> technically, i see nothing wrong with putting it after the choice.
> aesthetically and philosophically, i'd like to see that sort of thing allowed
> within the choice since it's so tightly related and, in effect, only *has*
> meaning in relation
Hi,
Robert P. J. Day wrote:
is there a proper way to place that "calculated" value representing
"yes, something non-null was selected" inside the choice construct
without getting a kbuild warning? really, that's where it belongs.
Why do you want to put it within the choice? I see nothing wrong
Hi,
On Sun, 15 Aug 2004, Geert Uytterhoeven wrote:
> > What about normal numbers? I don't think requiring quotes everywhere for
> > this is a good idea.
>
> And numbers (both decimal and hex) can easily be distinguished from y, n, and m
> anyway.
I did consider this at some point, but I didn't
Hi,
On Sat, 14 Aug 2004, Adrian Bunk wrote:
> > This is less a problem, as here it's clear that you want a boolean result,
> > but something like "FOO=n" is really a string compare and FOO could be of
> > any type (that 99% of all symbols are boolean/tristate symbols doesn't
> > really help).
Hi,
On Thu, 12 Aug 2004, Adrian Bunk wrote:
> > Roman, a related Q.
> > Why not error out, or at least warn when encountering an unknow
> > symbol in a 'depends on' statement?
> >...
>
> That doesn't sound like a good idea, consider e.g.:
>
> config BAGETLANCE
> tristate "Baget AMD LANC
Hi,
On Wed, 11 Aug 2004, Adrian Bunk wrote:
> Roman, is it intentional that PCMCIA!=n is true if there's no PCMCIA
> option, or is it simply a bug?
Yes, undefined symbols have a (string) value of "" . Maybe it's time to
add a warning for such comparisons...
bye, Roman
--
Hi,
On Mon, 19 Jul 2004, Chris Lingard wrote:
> When qt is installed in /usr, then there is no need to set and
> export QTDIR; but make xconfig expects this.
What distribution are you using? This would mean all qt header files are
directly in /usr/include.
> This patch adds /usr to the script,
Hi,
Sebastian Henschel wrote:
Your mailer ate the archive, it doesn't look that big, could you include
them uncompressed? This would also make it easier to quote them if needed.
Kconfig.if: i prefer this version the most, though it simply does not
work, i do not understand why and perhaps this
Hi,
On Fri, 6 Feb 2004, Andreas Gruenbacher wrote:
> > config NFSD_ACL
> > bool "..."
> > depends on NFSD_V3
> > select NFS_ACL_SUPPORT if NFSD
> >
> > you avoid the warning and it does the same.
>
> Does it? I would assume this to limit NFS_ACL_SUPPORT to y or n
> depending on the va
Hi,
On Fri, 6 Feb 2004, Andreas Gruenbacher wrote:
> With this configuration, menuconf gives me this message (among others):
>
> Warning! Found recursive dependency: NFSD_V3 NFSD_ACL NFSD NFSD_V3
This is indeed a wrong positive, the patch below fixes this, but you if
change your config into e.
Hi,
Russell King wrote:
Essentially, it appears a default selection in a choice statement takes
precidence over an explicit select statement for one of the choice
options.
Actually a select statement has currently no effect on choice values,
because it's undefined what effect it should have. The
Hi,
On Thu, 12 Jun 2003, Joe Korty wrote:
> The (undocumented) kbuild 'menuconfig' command,
Not anymore with 2.5.71. :)
> eg, as used by the
> CONFIG_EMBEDDED configurable, does not behave well under 'make gconfig'.
I know and you have to ask Romain Lievin for a fix.
> Also, it would be nice
Hi,
Robert Schwebel wrote:
> is a standalone converter script from cml1 to kconfig still available
> somewhere? I remember having read that there was one during the 2.5
> inclusion.
It's at http://www.xs4all.nl/~zippel/lc/old/lkc-1.2.tar.gz
'make lkcc' builds the converter and with 'lkcc ' you c
Hi,
On Thu, 7 Nov 2002, Peter Samuelson wrote:
> Even if this is true - I'll grant you that it may be - let the vendor
> package /usr/bin/qconf as a shell script that links /usr/lib/qconf.o
> with -lqt and $(LINUX)/scripts/kconfig/libkconfig.a . It's a little
> unorthodox, but it removes the hac
Hi,
On Thu, 7 Nov 2002, Peter Samuelson wrote:
> > Shared libraries can be loaded dynamically, this means distribution can
> > package the graphical front ends and the user doesn't need to install
> > huge development packages.
>
> I still don't get it. Why can't the distribution vendor just
Hi,
On Thu, 7 Nov 2002, Peter Samuelson wrote:
> > If you want to limit people to the config tools in the kernel, there
> > is indeed no need for a shared library. Note that during the next
> > development cycle all graphical front ends are possibly removed.
>
> Huh? I don't get it. How is a s
Hi,
On Thu, 7 Nov 2002, Peter Samuelson wrote:
> Basically, what I'm saying is, I see no need for the existing .so in
> the kernel build, much less another one. Static libraries are ever so
> much easier to manage.
If you want to limit people to the config tools in the kernel, there is
indeed
Robert Schwebel wrote:
> config GNU_TARGET
> string "i386-linux" if OPT_I386
> string "i486-linux" if OPT_I486
> string "i686-linux" if OPT_I686
> string "arm-linux" if OPT_ARM4
> default "-not configured-"
>
> for example give
>
> GNU_TARGET="arm-linux
Hi,
On Tue, 29 Oct 2002, Tom Rini wrote:
> > Even smaller? What do you mean?
>
> Well, less lines. Is:
> config FTR_A bool default y if BOARD_A
> legal ?
No, and without a good reason I'd rather avoid this.
bye, Roman
---
This sf.net emai
Hi,
On Wed, 30 Oct 2002, Erik Andersen wrote:
> It seems that 2.5.45 does not exist. Is this vs a BK snapshot?
http://marc.theaimsgroup.com/?l=linux-kernel&m=103595086131620&w=2
Argh, so I removed 1.3 too. If anyone has problems during 'make xconfig',
although he has the qt development package
Hi,
At http://www.xs4all.nl/~zippel/lc/ you can find as usual the latest
version of the new config system.
Changes:
- Update to 2.5.45
- Detect a few more qt settings (e.g. multithreaded library, qt path)
and remember it.
bye, Roman
---
This s
Hi,
On Tue, 29 Oct 2002, Tom Rini wrote:
> Now, can that be done any smaller? (one line, after it's defined once)
Even smaller? What do you mean?
bye, Roman
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thin
Hi,
Tom Rini wrote:
> How would I do this with the new syntax, other than:
> config FTR_A
>bool
>depends on BOARD_A || BOARD_B
>default y
> ...
>
> The desire is to be able to add in support for a new platform, without
> having to rely on much context to patch (or, have a file be
> a
Hi,
At http://www.xs4all.nl/~zippel/lc/ you can find the latest version of
the new config system.
Changes:
- qconf ui improvements.
- the parser is compiled as a single file (which includes the other
source files), which should speed up the compile a bit and might
simplify kbuild.
A small comment
Hi,
Here is now the final release (it's as usual at http://www.xs4all.nl/~zippel/lc/ ).
Changes in this release:
- help texts are a bit more indented (by two spaces) and long texts (more
than 10 lines), start with "---help---".
- in preparation of the library API I renamed a few structures/symbols
Hi,
On Tue, 15 Oct 2002, Adrian Bunk wrote:
> $ cd /tmp/
> $ tar xzf lkc-0.9.tar.gz
> $ cd lkc-0.9
> $ make
> ...
> $ cd ~/linux/kernel-2.5
> $ tar xzf linux-2.5.42.tar.gz
> $ cd linux-2.5.42
> $ bzcat /tmp/lkc-0.9-2.5.42.diff.bz2 |patch -p1
> ...
> $ /tmp/lkc-0.9/lkcc i386
Umm, now I see the p
Hi,
On Tue, 15 Oct 2002, Adrian Bunk wrote:
> recursive dependency: ISDN_DRV_EICON_DIVAS ISDN_DRV_EICON_OLD (choice(2) detected)
>ISDN_DRV_EICON_DIVAS
> recursive dependency: AEDSP16_MSS AEDSP16_SBPRO (choice(1) detected) AEDSP16_MSS
> recursive dependency: INPUT_GAMEPORT INPUT_GAMEPORT
> recur
Hi,
On Mon, 14 Oct 2002, Greg KH wrote:
> I get the following error on Red Hat 7.2:
>
> g++ -O2 -Wall -g -fPIC -I/usr/lib/qt-2.3.1/include -c qconf.cc -o qconf.o
> In file included from lkc.h:10,
> from qconf.cc:22:
> zconf.tab.h:8: conflicting types for `typedef union YYSTYPE Y
Hi,
At http://www.xs4all.nl/~zippel/lc/ you can find as usual the latest
version of the new config system.
I still haven't got a single mail from someone who tried it and didn't
like it, what makes me a bit nervous :), so if you think something must
be wrong, now is your last chance. Next version
Hi,
On Wed, 9 Oct 2002, Jeff Garzik wrote:
> Which implies that the equivalent of "source drivers/net/Config*"
> (wildcarding) in Roman's system would be useful. Or maybe "source
> drivers/net" and it knows that when given a directory it should scan for
> all Config* files in that dir.
This ma
Hi,
On Wed, 9 Oct 2002, Christoph Hellwig wrote:
> Why don't you just separate the library from the kernel at all, making
> it a similar package. We depend on a few external, kernel-specific
> packages anyway, and depending on libkconfig wouldn't make the situation
> worse.
The problem is that
Hi,
On Wed, 9 Oct 2002, Randy.Dunlap wrote:
> So I think that you and Roman are close to agreement, when Roman
> has the library backend ready. Of course someone needs to do a
> "reference implementation" with it also, but it doesn't need to
> ship with the kernel.
We ship BK documentation, so
Hi,
On Wed, 9 Oct 2002, J.A. Magallon wrote:
> >stick with TCL/TK, like xconfig currently uses ?
> >or is it not sufficient? or just too ugly?
> >
>
> What is linux kernel conf written in ?
> - perl: use perl-gtk (I think there is also a perl-qt)
> - python: use py-gtk...
>
> Use whatever the l
Hi,
On Thu, 10 Oct 2002, Brendan J Simon wrote:
> As you can see there are soo many guis to choose/use and everyone
> has there favourite. I suggest that the real work be done outside of
> the GUI program. ie. seperate GUI and application guts as much as
> possible. I would use python as
Hi,
On Wed, 9 Oct 2002, Jeff Garzik wrote:
> Well, my basic preference is
>
> * something other than Config.new (the original name in your config system)
> * something other than Config.in
>
> I think it is a mistake to name a totally different format the same name
> as an older format... even
Hi,
On Tue, 8 Oct 2002, Linus Torvalds wrote:
> I'm not super-excited about this, partly because of the brouhaha last time
> around on this issue.
>
> This has reasonably distributed config files, and puts the help with the
> config entry where it belongs. Good. It also makes do with just standa
Hi,
At http://www.xs4all.nl/~zippel/lc/ you can find the latest version of
the new config system.
As already mentioned before lkc is pretty much ready (except for kbuild
integration).
Linus, do you have any interest in merging it in the near future? If
not, what's missing?
The 2.5.40 release sho
Hi,
(I almost forgot to reply to this one, sorry for the delay.)
On Sun, 22 Sep 2002, Kai Germaschewski wrote:
> I'm not particularly fond of these md5sum hacks. I don't think it's all
> that annoying for the developer, either, it's basically just a
> alias make="make LKC_GENPARSER=1"
>
> (Of c
Hi,
On Sun, 29 Sep 2002, Sam Ravnborg wrote:
> 1) Old tools zapped tags around filenames.
Ok.
> > An issue (which was also mentioned by Jeff Garzik) is the help text
> > format. Jeff likes to have an endhelp, where I think it's redundant.
> 2) The current way forces the layout of the help tex
Hi,
On Sat, 28 Sep 2002, Tomas Szepe wrote:
> > At http://www.xs4all.nl/~zippel/lc/ you can find the latest version of the
> > new config system. Besides the usual archive there is also now a patch
> > against a 2.5.39 kernel and finally some documentation.
>
> o lkc-0.7-2.5.39.diff includes pa
Hi,
On Sat, 28 Sep 2002, Tomas Szepe wrote:
> > At http://www.xs4all.nl/~zippel/lc/ you can find the latest version of the
> > new config system. Besides the usual archive there is also now a patch
> > against a 2.5.39 kernel and finally some documentation.
>
> o lkc-0.7-2.5.39.diff includes pa
Hi,
At http://www.xs4all.nl/~zippel/lc/ you can find the latest version of the
new config system. Besides the usual archive there is also now a patch
against a 2.5.39 kernel and finally some documentation. This patch I also
consider as my first release canditate, so please test this one carefully
Hi,
On Sun, 22 Sep 2002, Kai Germaschewski wrote:
> I'm still not happy at least for the ".config does not exist" case. Since
> when I forget to "cp ../config-2.5 .config", I don't really want "make
> oldconfig", I want to do the forgotten cp.
Adding this check to the silent mode is trivial.
b
Hi,
On Sun, 22 Sep 2002, Kai Germaschewski wrote:
> > One cosmetic thing I mentioned to Roman, Config.new needs to be changed
> > to something better, like conf.in or build.conf or somesuch.
>
> I agree. (But I'm not particularly good at coming up with names ;)
> build.conf is maybe not too bad
Hi,
On Fri, 20 Sep 2002, Sam Ravnborg wrote:
> I have been working on integrating lkc with kbuild.
> Here is the result.
Thanks, nice work. :)
> Rules.make
> - Added infrastructure to support host-ccprogs, in other words
> support tools written (partly) in c++.
There are all compiled with g
Hi,
On Wed, 11 Sep 2002, Sam Ravnborg wrote:
> make xconfig
> - Do some selections
> - Use mouse to select save icon on tool-bar
> - File|Quit
> ->Save Configuration? Press yes
> End result is an empty .config file
I've seen it once too, but I couldn't remember how to reproduce it, but I
now kn
Hi
On Tue, 10 Sep 2002, Jeff Garzik wrote:
> How about posting a kernel patch (or link to one) that you feel is
> suitable for 2.5.x integration? That makes it a bit easier to review in
> context, and may help to resolve any final integration issues.
That depends on what you want to see. The p
Hi,
At http://www.xs4all.nl/~zippel/lc/lkc-0.5.tar.gz you can find the
latest version of the new config system. Besides various small bug
fixes, it includes the following changes:
- Improved mouse interface of qconf
- qconf isn't build if QT isn't available
- "if" ... "endif" block added
- update
Hi,
On Fri, 6 Sep 2002, Greg Banks wrote:
> > I dislike the requirement to convert all existing config.in files to
> > support the new syntax. You already have the machinery to do the
> > conversion online as needed, so why not detect if config.in is newer
> > than config.lkc and if thats the ca
Hi,
On Thu, 5 Sep 2002, DervishD wrote:
> Thanks for taking the effort of making a better building process
> :) I hope you have success ;))
Thanks. :)
> Well, even though it is a beta release, please make the graphical
> interface optional. I've had to tweak the Makefile since I haven'
Hi,
I wrote:
> > 5) Tried to delete endmenu on line 610 in arch/i386/config.in:
> > ./scripts/lkc/mconf arch/i386/config.new
> > :0:parse error
> > This error message is not good enough.
>
> Known problem, but it's currently not very high on my TODO list.
BTW the main reason for this is that t
Hi,
At http://www.xs4all.nl/~zippel/lc/lkc-0.4.tar.gz you can find the
latest version of my config system. It slowly is becoming completely
usable, so it's time for a new release.
A lot has changed since the last official release, so here only some
highlights:
- correct dependencies for the confi
Hi,
Sam Ravnborg wrote:
> Found a slot to give it a spin:
> 1) Did not apply cleanly to 2.5.31. Makefile caused a reject.
> Other hunks went ok, but with an offset.
You probably had other patches applied?
> 2) When browsing in menuconfig the menus are repositioned depending of
> the length of
Hi,
At http://www.xs4all.nl/~zippel/lc/lkc-0.3.tar.gz you can find the latest
version of my config system. Over the weekend I was busy tuning/fixing the
converter to keep the new rulebase as close as possible to the old one.
Unless I made an error somewhere, the rulebase should be the same now. T
Hi,
On Thu, 22 Aug 2002, Greg Banks wrote:
> > Why do you want to do the parser/syntax switch separately? Why do you want
> > to write and test a parser just to be throw it away again?
>
> So that the changes have some chance of getting past Linus.
Sorry, but that's a dumb reason. Linus is quit
Hi,
On Wed, 21 Aug 2002, Greg Banks wrote:
> > I have to manually fix things like CONFIG_ALPHA_NONAME, which is first set
> > by a choice statement and later redefined. My new parser can't deal with
> > this, because user input is given the highest priority.
>
> Well then, there's something we n
Hi,
On Mon, 19 Aug 2002, Greg Banks wrote:
> If you wanted to add the ability to express this in CML1, you would need
> a completely different syntax for choices, say something like this:
>
> menuchoice next_comment
> comment 'Kernel page size'
> choiceitem '4KB' CONFIG_IA64_PAGE_SIZE_4K
Hi,
On Mon, 19 Aug 2002, Greg Banks wrote:
> Unlike you, I'm not optimistic that a switch to a new language or even a new
> parser for the old language will ever happen.
It would be nice if I could get it into 2.6, but it's not a problem if it
has to wait. I'm currently busy getting menuconfig
Hi,
Peter Samuelson wrote:
> +If you think in terms of Boolean algebra, most of the above rules make
> +sense if you think of each primitive value ("y", "m" and "n") as two
> +bits: "y"=11, "m"=01, "n"=00. Adjacent words are implicitly ANDed
> +together, and the "or" statement, with lower prece
Hi,
Peter Samuelson wrote:
> +If the dependency yields "m", the first block is executed and the
> +second skipped, just as with "y", but with one crucial difference: the
> +output for certain verbs is restricted. "bool" and "dep_bool"
> +statements are suppressed entirely; "tristate" and "dep_t
Hi,
On Fri, 16 Aug 2002, Peter Samuelson wrote:
> Basically the current discussion revolves around the best way to
> evolve the config language to make it more suitable for its purpose.
> This is of course in contrast to what ESR and you have tried, which is
> to replace the whole thing.
I have
Hi,
On Fri, 16 Aug 2002, Kai Germaschewski wrote:
> Oh well, I think the only way to find out if all that is really a good
> idea is to try, convert some config.in's and look at the result.
I really hate to spoil the fun, but could someone explain to me, why this
is necessary? What problems doe
Hi,
On Fri, 16 Aug 2002, Greg Banks wrote:
> The easy targets being done now are mostly things that I believe would need
> to be done regardless of the eventual strategy, be it a) do nothing b) make
> the existing system suck less c) replace the parsers and keep the rules
> d) replace everything
Hi,
On Thu, 15 Aug 2002, Kai Germaschewski wrote:
> Surely not all conceptual problems are fixable easily, they probably need
> to be done in conjunction with switching to a common parser etc. (Note:
> this switch to a new parser should happen with no change to the config.in
> format or semantic
Hi,
(Could you please fix your mailer? linux-m68k.org.com does not really
exist.)
On Thu, 15 Aug 2002, Greg Banks wrote:
> > The problems are really not simple, the current config language is very
> > limited, [...]
>
> I don't think anyone who actually understands the config system would
> arg
Hi,
On Tue, 13 Aug 2002, Peter Samuelson wrote:
> Mutating the language, long-term, so that it looks less like sh and
> more like a specialised language, is IMO a worthy goal. And I think
> it can be done. The main thing to deal with is adding an alternative
> syntax for 'if' statements which
Hi,
On Tue, 13 Aug 2002, Greg Banks wrote:
> > This doesn't has be
> > very painful, I have a tool that can convert most of the current config
> > into whatever you want.
>
> The problem is deciding what the original rules were supposed to mean, and
> then reproducing that behaviour exactly in t
Hi,
On Mon, 12 Aug 2002, Peter Samuelson wrote:
> tristate DRV
> dep_mbool DRV_OLD DRV
>
> dep_mbool COMMON_OPT DRV
> dep_mbool OLD_OPT1 DRV_OLD
> dep_mbool OLD_OPT2 DRV_OLD
> dep_mbool NEW_OPT1 DRV !DRV_OLD
> dep_mbool NEW_OPT2 DRV !DRV_OLD
This way you can't compile old and new driver as modu
1 - 100 of 114 matches
Mail list logo
