Brendan J Simon wrote:
>
> Greg Banks wrote:
>
> >>[*] "almost enough" because I haven't implemented an 'else'
> >>directive. It would be trivial, but I'm not sure what to call it.
> >>'else' itself is a shell primitive, so the shell-based parsers
> >>(Configure, Menuconfig) wouldn'
Peter Samuelson wrote:
> * 'or' placed between dependencies functions as a logical OR, and
> takes very low precedence. This complements the implicit AND
> performed between every pair of dependencies.
>
> x or x -> x, for any x
> n or m == m or n -> m
> n or y == y or n -> y
[Brendan J Simon]
> > Either if_dep, else_dep and end_dep _or ifdep, elsedep, enddep.
I like it. My original if_dep was ifdep, but I thought people would
mistake it for the common verb 'ifdef' and misspell it that way. So I
vote for the _s.
[Greg Banks]
> Yes, the _s should be consistent.
Greg, in regards to another question you had - no I don't think there
is value in having a variant if statement that treats 'm' differently.
You can already get the same effect by using 'CONFIG_FOO=y' or
'CONFIG_FOO=m' instead of plain 'CONFIG_FOO'.
You are much better than I at finding examples
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
On Thu, 15 Aug 2002, Roman Zippel wrote:
> > I don't think anyone who actually understands the config system would
> > argue these points, but we are limited by practical constraints to making
> > incremental improvements only.
>
> That's fine with me, but nonetheless I'd really like to know whe
On Wed, 14 Aug 2002, Sam Ravnborg wrote:
>
> Where comes the requirement that we shall keep the existing shell
> based config parsers?
I use them exclusively.
It is far and away the most convenient parsing - just to do "make
oldconfig" (possibly by making changes by hand to the .config file
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
[Giacomo A. Catenazzi]
> I don't like calling it "or"... It is error prone because it is a non
> binary system,
> thus can confuse the lazy developers.
I had to call it something. I for one think 'or' is quite intuitive
here. If you insist that OR can only be done on binary values, think
of '
[Kai Germaschewski]
> Honestly, I do not like this. It's probably the best that can be
> done in shell, but I think it's ugly and not intuitive.
I accept that it is not pretty. But unless we can switch to mconfig
or gcml2 or some other static parser for everything, we will need
shell-parsable s
Peter Samuelson wrote:
>
> Greg, in regards to another question you had - no I don't think there
> is value in having a variant if statement that treats 'm' differently.
> You can already get the same effect by using 'CONFIG_FOO=y' or
> 'CONFIG_FOO=m' instead of plain 'CONFIG_FOO'.
>
> You are m
Peter Samuelson wrote:
>
> [Giacomo A. Catenazzi]
> > I don't like calling it "or"... It is error prone because it is a non
> > binary system,
> > thus can confuse the lazy developers.
>
> [...]But
> nobody thinks of "max" as an infix operator, and infix is IMO the most
> natural way to express
Peter Samuelson wrote:
>
> [Kai Germaschewski]
> > Honestly, I do not like this. It's probably the best that can be
> > done in shell, but I think it's ugly and not intuitive.
> [...]
> The shell-syntax if [ ] might seem intuitive at first glance, if you
> already know the Bourne shell, but that
[Greg Banks]
> I was thinking that with your proposed syntax we'd have a large
> level of compatibility in both syntax and semantics between "if_dep"
> and "dep_bool", much more so than with "if" and "dep_bool"
As you said the other day, "This is not a coincidence." (:
But technically, if_dep c
Roman Zippel wrote:
>
> Hi,
>
> (Could you please fix your mailer? linux-m68k.org.com does not really
> exist.)
I believe the problem is upstream of the machine I control. I'll see what I can do.
> That's fine with me, but nonetheless I'd really like to know where it will
> go to. Just fixing
[John Alvord]
> I've been puzzling about this problem and the CML2 trainwreck.
>
> Maybe we can used advanced tools to remove the many bugs and
> inconsistancies and then switch to a better config tool.
That's exactly what we're trying to do. Greg has the advanced
consistency checking, and I'v
Peter Samuelson wrote:
>
> [Greg Banks]
> > I was thinking that with your proposed syntax we'd have a large
> > level of compatibility in both syntax and semantics between "if_dep"
> > and "dep_bool", much more so than with "if" and "dep_bool"
>
> As you said the other day, "This is not a coinci
[Greg Banks]
> Sure, but with something like "if_dep" <-> "dep_bool" and "if_mdep"
> <-> "dep_mbool" there exists a simple and bidirectional textual
> rearrangement which completely preserves semantics, to go between
> using the if and using the dep_*. This means people can safely
> switch betwe
Peter Samuelson wrote:
>
> The more I think about it, the more I think the default if_dep should
> do the m-restricting thing. That way:
>
> dep_bool FOO1 BAR BAZ
> dep_mbool FOO2 BAR BAZ
> dep_tristate FOO3 BAR BAZ
>
> is exactly equivalent to
>
> if_dep BAR BAZ
> bool FOO1
>
On Wed, 14 Aug 2002, Peter Samuelson wrote:
> I've reused the syntax for a dependency line (the tail end of a
> dep_bool / dep_mbool / dep_tristate), like so:
>
> if_dep dependency line
> ...
> endif
Honestly, I do not like this. It's probably the best that can be done in
shell, but I
20 matches
Mail list logo
