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't like it.
You will need to implement
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't like it.
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
m
[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
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
argue
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 where it
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
[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
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 a
[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 corresponds
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 the
[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've
14 matches
Mail list logo
