On Tue, 22 May 2001 11:24:54 +0200,
Daniel Phillips <[EMAIL PROTECTED]> wrote:
>On Tuesday 22 May 2001 02:59, Keith Owens wrote:
>> # Not a real dependency, this checks for hand editing of .config.
>> $(KBUILD_OBJTREE)include/linux/autoconf.h: $(KBUILD_OBJTREE).config
>> @echo Your .confi
Jonathan Morton <[EMAIL PROTECTED]>:
> I'm going to assume for now that CML2 saves two files - one storing a
> relatively small number of symbols (which is strictly limited to those
> explicitly set by the user), and one containing the full set for
> consumption by the Makefiles.
No, that's not t
On Tuesday 22 May 2001 16:42, john slee wrote:
> On Mon, May 21, 2001 at 10:00:07PM +0200, Urban Widmark wrote:
> > On Mon, 21 May 2001, Eric S. Raymond wrote:
> > > the NEW tag). That phase ended almost a month ago. Nobody who
> > > has actually tried the CML2 tools more recently has reported t
[EMAIL PROTECTED] said:
> I don't agree with this, since the current CML1 scheme has wierd,
> unwanted and wrong dependencies already, which can't (or haven't) been
> found. Since it would be put in during the 2.5.x branching, it's
> expected that things will/can/should break, so I don't think
David> You appear to be responding to my email, yet you did not do me
David> the courtesy of including me in the recipients. Should I assume
David> you're asking this question of me directly, or was it a
David> rhetorical question?
It was more of an attempt to cutdown on the number of recipients
On Tuesday 22 May 2001 02:59, Keith Owens wrote:
>
> # Not a real dependency, this checks for hand editing of .config.
> $(KBUILD_OBJTREE)include/linux/autoconf.h: $(KBUILD_OBJTREE).config
> @echo Your .config is newer than include/linux/autoconf.h,
> this should not happen. @echo Always r
On Mon, May 21, 2001 at 10:00:07PM +0200, Urban Widmark wrote:
> On Mon, 21 May 2001, Eric S. Raymond wrote:
>
> > the NEW tag). That phase ended almost a month ago. Nobody who has
> > actually tried the CML2 tools more recently has reported that the UI
> > changes present any difficulty.
>
>
[EMAIL PROTECTED] said:
> David> for the sake of the sanity of all concerned, do things one at a
> David> time. Provide for merging into 2.5 a set of rules which
> David> reproduce the existing CML1 behaviour in this respect.
> Can you define what you mean here? It's not really clear to me, an
Urban Widmark <[EMAIL PROTECTED]>:
> What happened with the discussion on configurable colors in make
> menuconfig? Darkblue on black as frozen options get isn't exactly optimal
> ... at least not for my eyes. Being next to a bold, white text doesn't
> help either.
Nobody could come up with a way
On Mon, 21 May 2001 16:38:34 -0400,
John Stoffel <[EMAIL PROTECTED]> wrote:
>All that CML2 does is enforce dependencies in the configuration
>language. You can't make a .config which conflicts. Admittedly
>there's nothing stopping you from hacking it with vi after the fact,
>but why?
CML2 will
>If you run into a case where you have a config which would work, but
>CML2 doesn't let you, why don't you fix the grammar instead of saying
>CML2 is wrong? Let's not confuse these two issues as well.
Strongly agree. Especially since I'm pushing for an explicit recognition
of the difference bet
David> Actually, the current system has both types. As well as the
David> "hard" dependencies, we also have stuff like
David> CONFIG_PARTITION_ADVANCED, CONFIG_CPU_ADVANCED,
David> CONFIG_FBCON_ADVANCED, CONFIG_MTD_DOCPROBE_ADVANCED,
David> etc. CONFIG_EXPERIMENTAL serves a very similar purpose,
On Mon, 21 May 2001, Eric S. Raymond wrote:
> the NEW tag). That phase ended almost a month ago. Nobody who has
> actually tried the CML2 tools more recently has reported that the UI
> changes present any difficulty.
What happened with the discussion on configurable colors in make
menuconfig?
On 05/21/2001 at 12:58:57 [EMAIL PROTECTED] wrote:
>CML2 drops its configuration results in the same place, in the same
>formats, as CML1. So you should in fact be able to type `make menuconfig'
>and `make oldconfig' with good results. Have you actually tried this?
No, I haven't tried it yet
[EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> Speaking from the perspective of a user of the CML tools, rather
> than as a developer, all I've been trying to say is this: When I
> type "make menuconfig" or "make oldconfig" in the future, I want to
> see the same interface and the same results that I've
On 05/21/2001 at 05:04:40 AM [EMAIL PROTECTED] wrote:
>See, I've already written off the chronic bellyachers. Since I can't
>please them without scrapping the whole plan, I'm going to ignore
>them. In particular, anybody who repeated "fsck Python..." after Linus
>ruled that Python is not an i
> > 2) Have a HACKERS submenu system which contains all the derivations
> > that could *possibly* be un-defaulted, and allow our intrepid hacker
> > to explicitly force each to a value or leave unset.
>
> I prefer the former, which is how it's already implemented in CML1.
Its called Debugging in
[EMAIL PROTECTED] said:
> Having now briefly looked at the language constructs first-hand, I
> can see two ways to go about this:
> 1) Have a HACKER symbol which unsuppresses the "unusual" options, and
> suppresses the "generalised" ones
> 2) Have a HACKERS submenu system which contains all t
>> order to hold down ruleset complexity and simplify the user
>> experience. The cost of deciding that the answer to that question is
>
>The user experience can be simplified by a NOVICE/EASY/SANE_DEFAULTS
>option, and perhaps a HACKER option for the really strange
>but _theoretically_ ok stuff.
[EMAIL PROTECTED] said:
> I don't think there is a "less contentious" part. The same people who
> bitched about the engine are now bitching about the changes I'm
> contemplating in the rulesfiles. It seems clear to me that their
> attitude, in general, has little to do with technical specifics
David Woodhouse <[EMAIL PROTECTED]>:
> Because it is evidently confusing the issue. Perhaps because it sounds like
> you were intending to feed Linus large patches for 2.5.[12] which effect
> _both_ changes.
I'm going to give Linus the same installation kit the people working with CML2
have now
"Eric S. Raymond" wrote:
>
> To reduce the problem further, I looked for symbols with missing
> entries that I could turn into derivations, eliminating their
> questions and the requirement for a help entry.
Adding help entries is nice. But please don't go around
making "unlikely" choices un
[EMAIL PROTECTED] said:
> What discussion is that? Unless Linus has changed his mind and I
> don't know about it, CML2 is going in between 2.5.1 and 2.5.2.
Because it is evidently confusing the issue. Perhaps because it sounds like
you were intending to feed Linus large patches for 2.5.[12]
On 20 May 2001, Robert M. Love wrote:
> I feel that there should *never ever* be a legit situation that the
> configuration tool does not allow. Not ever. Two reasons:
>
> First, I tend to trust the config tools (perhaps too much). If they
> tell me x implies y, or x implies not y, I will beli
On Sun, 20 May 2001, Eric S. Raymond wrote:
> In order to prevent that happening, I would like to have some recognized
> criterion for configuration cases that are so perverse that it is a
> net loss to accept the additional complexity of handling them within the
> configurator.
Simple: That
> derive MVME147_SCSI from MVME147 & SCSI
It seems that the preferred semantics would be:
default MVME147_SCSI from MVME147 & SCSI
That way the platform defines sane defaults, but no flexibility has been
taken away.
Presumably many of these defaulted options would also be ones that would
be co
David Woodhouse <[EMAIL PROTECTED]>:
> Let's not talk about CONFIG_AUNT_TILLIE any more, or change the existing
> behaviour of config options to make that the default, until we've settled
> the discussion about CML2.
What discussion is that? Unless Linus has changed his mind and I don't
know ab
> "Eric" == Eric S Raymond <[EMAIL PROTECTED]> writes:
Eric> The first candidates I found were questions associated with
Eric> built-in SCSI and Ethernet on Macintoshes, on the Sun 3 and
Eric> Sun3x, and with built-in facilities on the MVME147 single-board
Eric> computer. So I wrote derivati
[EMAIL PROTECTED] said:
> Maybe it would be possible to separate "hard" dependencies like the
> current system has with the "soft" ones one needs for entry-level
> configtools.
Actually, the current system has both types. As well as the "hard"
dependencies, we also have stuff like CONFIG_PARTIT
On 20 May 2001 16:47:00 -0400, Eric S. Raymond wrote:
> In order to prevent that happening, I would like to have some recognized
> criterion for configuration cases that are so perverse that it is a
> net loss to accept the additional complexity of handling them within the
> configurator.
>
> A
On Sun, May 20, 2001 at 04:47:00PM -0400, Eric S. Raymond wrote:
> In order to prevent that happening, I would like to have some recognized
> criterion for configuration cases that are so perverse that it is a
> net loss to accept the additional complexity of handling them within the
> configurat
[EMAIL PROTECTED] said:
> I'm nervous that if we go down this path we will end up with a
> thicket of modes and a combinatorial explosion in ruleset complexity,
> leading immediately to a user configuration experience that is more
> complex than necessary, and eventually to an unmaintainable me
David Woodhouse <[EMAIL PROTECTED]>:
> I think you already have the mechanism required to answer this - in NOVICE
> mode you disallow the strange choices, in EXPERT mode you allow them.
That pushes the third button. I'm nervous that if we go down this path
we will end up with a thicket of modes
Jonathan Morton <[EMAIL PROTECTED]>:
> One caveat though - not all Macs have SCSI controllers, and not all that do
> even have one of the two standard ones.
I know. But these derivations are only for the old 68K macs, which don't
have PCI. Closed issue.
> >3. The MVME derivations are correct *
>1. The Mac derivations were half-right. The MAC_SCC one is good but Macs
>can have either of two different SCSI controllers. I fixed that with help
>from Ray Knight, who maintains the 68K Mac port.
If I understand the "philosophy" correctly, it is still possible to specify
additional cards for
Thankyou for the clarification.
[EMAIL PROTECTED] said:
> I used case 3 to explore a touchy question about design philosophy,
> which is really what caused all hell to break loose. The question is
> this: holding down configuration complexity is a good thing, but
> supporting all hardware conf
Those of you who have become confused about the current argument over CML2
should read this...
David Woodhouse <[EMAIL PROTECTED]>:
> After the discussion of MAC and SCSI config options many moons ago in this
> thread, I was left with the impression that the constraints which were
> being object
37 matches
Mail list logo
