On Fri, 18 May 2001 09:41:51 +0200 (CEST),
Kai Germaschewski [EMAIL PROTECTED] wrote:
On Fri, 18 May 2001, Keith Owens wrote:
I plan to remove CPP and CPPFLAGS, replacing $(CPP) with $(CC) -E
throughout and merging CPPFLAGS into [AC]FLAGS. This change will make
it much easier to handle
On Fri, 18 May 2001, Keith Owens wrote:
That is precisely my problem, it is not done cleanly at the moment.
We currently have, in roughly this order
global cppflags in top level makefile
include list from top level makefile
module/kernel flags from top level makefile
global cflags
On Fri, 18 May 2001 12:44:31 +0200 (CEST),
Kai Germaschewski [EMAIL PROTECTED] wrote:
Okay, I think you're right, the logical separation is not worth the
additional complexity. But why not leave the CPP variable at least?
On second thoughts I will keep CPP, it is a useful indication that the
Christoph Hellwig wrote:
On Fri, May 18, 2001 at 11:51:28AM -0400, John Cowan wrote:
Jes Sorensen wrote:
Telling them to install an updated gcc for kernel compilation
is a necessary evil, which can easily be done without disturbing the
rest of the system. Updating the system's python
On Fri, 18 May 2001, Eric S. Raymond wrote:
That being the case, we do face a question of design
philosophy, expressed as a policy question about how to design
rulesets. Actually two questions:
1. When we have a platform symbol for a reference design like MVME147, do
we stick to its
Alan Cox [EMAIL PROTECTED]:
I don't want to do (a); it conflicts with my design objective of
simplifying configuration enough that Aunt Tillie can do it. I won't
do that unless I see a strong consensus that it's the only Right Thing.
Its a good way of getting the defaults right. It may
Michael Meissner [EMAIL PROTECTED]:
On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote:
Aunt Tillie shouldn't try to manually configure a kernel.
Ummm, maybe Aunt Tillie wants to learn how to configure a kernel After
all, all of us at one point in time were newbies in
Hi Alan,
CML1 has had no official maintainer for about 4 years. People contribute bits
and it works. So as it stands there would be no reason to remove it.
Actually, I actively maintained all three config tools for several months
just before the 2.2 release (January 1999). Then I went back
My two cents:
I'm in favor of a new description language.
I'm in favor of new tools for processing it.
I'm comfortable with Python as an implementation language. The speed
problems seem to be under control.
It would be nice if either (a) the tools ran with Python 1.5.2 or (b)
some more time
Michael Elizabeth Chastain [EMAIL PROTECTED]:
My two cents:
I'm in favor of a new description language.
I'm in favor of new tools for processing it.
If you, wearing your CML1 maintainer hat, hadn't made these things clear
a year ago ago, CML2 wouldn't exist today.
I'm comfortable with
Eric Raymond writes:
That's exactly the approach I've taken until very recently. But the
compiler and configurator codebase is stable now. It seemed to me
time to think about improving the rulebase.
Ah, that is where we have different views. I think CML2 would be better
off if you shelved
Michael Elizabeth Chastain [EMAIL PROTECTED]:
Ah, that is where we have different views. I think CML2 would be better
off if you shelved improving the rulebase and focussed on integrating
into the kernel.
It's a drop-in install now. Is there something else specific you think I
could be
On Fri, 18 May 2001 14:41:22 -0400,
Eric S. Raymond [EMAIL PROTECTED] wrote:
Michael Elizabeth Chastain [EMAIL PROTECTED]:
It would be nice if either (a) the tools ran with Python 1.5.2 or (b)
some more time elapses and lots more people have Python 2.0 installed.
I think we'll get (b). 2.5
Keith Owens [EMAIL PROTECTED]:
Please, please never loose sight of the requirement for kbuild to work
on non-Linux platforms. People cross compile kernels from Solaris,
HP/UX, Cygwin, etc.
Python 2.0 runs quite nicely under the Macintosh OS, other Unixes and Cygwin.
You could even
Alan Cox [EMAIL PROTECTED]:
I was under the impression the MVME had VME bus. So you can hang IDE off it
and other gunge. Its also a reference design so you may find MVME147 like
boards..
Urk. Alan is right, I misinterpreted the original question. There is
no on-board support for IDE or
Keith == Keith Owens [EMAIL PROTECTED] writes:
Keith cc trimmed back to mailing lists only. On Fri, 18 May 2001
Keith 10:53:53 -0400, Eric S. Raymond [EMAIL PROTECTED] wrote:
(a) Back off the capability approach. That is, accept that people
doing configuration are going to explicitly and
For CML1 and CML2 to handle the same language, we would either have
to live with the CML1 language's limitations or retrofit the old tools
to speak CML2 language. The chance of the latter happening is, I think
we can agree, effectively zero.
Being able to turn CML2 into CML1 might be the
On Fri, May 18, 2001 at 12:34:13PM -0400, Eric S. Raymond wrote:
Even supposing somebody were loony enough to do that, how would preserving
an old interface in amber do anything to explore new UI possibilities?
I don't know about the rest of the world, but I _much_ prefer the old
menuconfig to
The latest version is always available at http://www.tuxedo.org/~esr/cml2/
Release 1.4.5: Fri May 18 02:02:27 EDT 2001
* Rulesfile updated for 2.4.5pre3, 2.4.4ac10.
The project page now also includes a download URL for the latest
version of the Configure.help file. It features over 340
Jes Sorensen wrote:
Telling them to install an updated gcc for kernel compilation
is a necessary evil, which can easily be done without disturbing the
rest of the system. Updating the system's python installation is not a
reasonable request.
Au contraire. It is very reasonable to have
(c) Decide not to support this case and document the fact in the
rulesfile. If you're going put gunge on the VME bus that replaces
the SBC's on-board facilities, you can hand-hack your own configs.
In general this is the best option, if you create a non-standard
That's ok as long as she doesn't add backstreet boys songtexts as long as your
signature to her mails.
I wouldn't worry. She'd be swimming to Cuba in search of asylum from the MPAA
if she did
Your point is basically:
Lets rewrite the kernel in VBA to make every word user
On Fri, May 18, 2001 at 12:04:34PM -0400, Eric S. Raymond wrote:
Alan Cox [EMAIL PROTECTED]:
I don't want to do (a); it conflicts with my design objective of
simplifying configuration enough that Aunt Tillie can do it. I won't
do that unless I see a strong consensus that it's the only
if you punt in case C you should then have a mode where all dependancies
are ignored and all options are presented to the person ding the config.
This is FAR better then forcing them to hand-hack the config file.
possibly split the rules file into two parts.
part 1. absolute requirements (i.e.
Alan Cox [EMAIL PROTECTED]:
In general this is the best option, if you create a non-standard
configuration for machine foo then it is your problem, not everybody
else's.
Which makes CML2 inferior to CML1 again. Now if it could parse CML1 rulesets
this whole discussion wouldn't be
On Fri, May 18, 2001 at 01:22:35PM -0400, Eric S. Raymond wrote:
Michael Meissner [EMAIL PROTECTED]:
On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote:
Aunt Tillie shouldn't try to manually configure a kernel.
Ummm, maybe Aunt Tillie wants to learn how to configure a
Eric == Eric S Raymond [EMAIL PROTECTED] writes:
Eric Jes Sorensen [EMAIL PROTECTED]:
For a start, so far there has been no reason whatsoever to change
the format of definitions.
Eric The judgment of the kbuild team is unanimous that you are
Eric mistaken on this. That's the five people
On Fri, May 18, 2001 at 11:51:28AM -0400, John Cowan wrote:
Jes Sorensen wrote:
Telling them to install an updated gcc for kernel compilation
is a necessary evil, which can easily be done without disturbing the
rest of the system. Updating the system's python installation is not a
On 05/18/2001 at 02:44:07 PM [EMAIL PROTECTED] wrote:
But the real question is whether the old tools have enough value to be
worth the effort. What problem are you trying to solve here?
How about:
1. Some of us are perfectly satisfied with the existing tools and don't want
them to
But the real question is whether the old tools have enough value to be
worth the effort. What problem are you trying to solve here?
Im just playing with ideas and writing a CML1 parser for amusement while I
ponder single pass computation of the entire dependancy graph from a CML1
rule base 8)
On Fri, May 18, 2001 at 12:34:13PM -0400, Eric S. Raymond wrote:
Alan, it sounds very much like you just said something stupid. This
seems sufficiently unlikely that I am shaking my head in disbelief and
fingernailing wax out of both ears (and if you think doing both those
things at once is
On Fri, 18 May 2001, Eric S. Raymond wrote:
Tom Rini [EMAIL PROTECTED]:
SCSI emulation over IDE, CONFIG_BLK_DEV_IDESCSI. You have the SCSI mid
layer code but no SCSI hardware drivers. It is a realistic case for an
embedded CD-RW appliance.
Or alternatively, you want to
Alan Cox [EMAIL PROTECTED]:
What I am trying to say is that if you can infer probable configuration
categories that are relevant then instead of automatically filling the other
areas in and blocking changing them without using vi you can put the other
options as a submenu. That guides the
On 05/18/2001 at 02:44:07 PM [EMAIL PROTECTED] wrote:
But the real question is whether the old tools have enough value to be
worth the effort. What problem are you trying to solve here?
How about:
1. Some of us are perfectly satisfied with the existing tools and don't want
them to
Alan Cox [EMAIL PROTECTED]:
Being able to turn CML2 into CML1 might be the more useful exercise.
That's...not a completely crazy idea. Hmmm...
It might be possible to take a CML2 rulebase and generate a sort of stupid
jackleg CML1 translation of it. The resulting config.in would be huge
and
35 matches
Mail list logo
