On Thu, 29 Nov 2001 23:42:11 -0500,
"Eric S. Raymond" <[EMAIL PROTECTED]> wrote:
>Keith Owens <[EMAIL PROTECTED]>:
>> # grep BLUEZ config.out
>> config.out:CONFIG_BLUEZ=n
>> config.out:CONFIG_BLUEZ_L2CAP=n
>> config.out:CONFIG_BLUEZ_HCIUSB=n
>> config.out:CONFIG_BLUEZ_HCIUART=n
>> config.out:CON
Keith Owens <[EMAIL PROTECTED]>:
> The main visibility problem I reported against cml2 1.9.1 has been
> fixed in 1.9.3, but there is still one peculiarity.
>
> # rm .config config.out rules.out
> # yes '' | make oldconfig
>
> Although make oldconfig only asks about
> BLUEZ: Bluetooth subsystem
"Eric S. Raymond" wrote:
>
> John Cowan has proposed allowing the default expression in a choice to be
> a string-valued derive that must be the name of a choice. This kind of
> type punning makes me cringe, and anyway it would be hard to check at compile
> time that the returned string is ne
The main visibility problem I reported against cml2 1.9.1 has been
fixed in 1.9.3, but there is still one peculiarity.
# rm .config config.out rules.out
# yes '' | make oldconfig
Although make oldconfig only asks about
BLUEZ: Bluetooth subsystem support < > (NEW)?:
the generated config.out con
The latest version is always available at http://www.tuxedo.org/~esr/cml2/
Release 1.9.3: Thu Nov 29 17:16:57 EST 2001
* Oops -- make sure Configure.help is included in the tarball!
* Rulebase update for SOUND_IT8172.
* Go back to using -I for oldconfig.
I made an error i
On Thu, 29 Nov 2001 16:28:00 +0100,
Giacomo Catenazzi <[EMAIL PROTECTED]> wrote:
>Keith Owens wrote:
>> This is my list from 2.4.16. A lot are false positives, but some are
>> definitely orphaned. If you spot any errors in the Makefile.in rules
>> compared to Makefile, let me know.
>
>I have ch
> Suppose we have split declarations for derivations or defaults of
> symbols that are shared across architectures. It would then be
> locally convenient for configuration maintainers to move these
> declarations from the top-level rules.cml file piecemeal to rules
> files in different arch subt
On Thu, Nov 29, 2001 at 02:48:50PM -0500, Eric S. Raymond wrote:
> Tom Rini <[EMAIL PROTECTED]>:
> > On Thu, Nov 29, 2001 at 02:20:05PM -0500, Eric S. Raymond wrote:
> > > Tom Rini <[EMAIL PROTECTED]>:
> > > > Then what's wrong with putting these in arch/$(ARCH)/rules.cml, or
> > > > arch/$(ARCH)/
Tom Rini <[EMAIL PROTECTED]>:
> On Thu, Nov 29, 2001 at 02:20:05PM -0500, Eric S. Raymond wrote:
> > Tom Rini <[EMAIL PROTECTED]>:
> > > Then what's wrong with putting these in arch/$(ARCH)/rules.cml, or
> > > arch/$(ARCH)/boot/rules.cml ?
> >
> > Nothing. But if they aren't single declarations,
On Thu, Nov 29, 2001 at 02:20:05PM -0500, Eric S. Raymond wrote:
> Tom Rini <[EMAIL PROTECTED]>:
> > Then what's wrong with putting these in arch/$(ARCH)/rules.cml, or
> > arch/$(ARCH)/boot/rules.cml ?
>
> Nothing. But if they aren't single declarations, what's going to
> *keep* them there?
Wha
Tom Rini <[EMAIL PROTECTED]>:
> Then what's wrong with putting these in arch/$(ARCH)/rules.cml, or
> arch/$(ARCH)/boot/rules.cml ?
Nothing. But if they aren't single declarations, what's going to
*keep* them there?
--
http://www.tuxedo.org/~esr/";>Eric S. Raymond
Question with
On Thu, Nov 29, 2001 at 02:06:40PM -0500, Eric S. Raymond wrote:
> Tom Rini <[EMAIL PROTECTED]>:
> > > Information distributed through the ruleset in such a way that it's hard
> > > to know all the places a given symbol participates.
> >
> > On the compiler side of things or the human side of thi
Eric S. Raymond wrote:
> Information distributed through the ruleset in such a way that it's hard
> to know all the places a given symbol participates.
But that's what xref tools are made for. In the kernel, the directory
(or even the file) is the unit of ownership. I argue that stuff like
t
Tom Rini <[EMAIL PROTECTED]>:
> > Information distributed through the ruleset in such a way that it's hard
> > to know all the places a given symbol participates.
>
> On the compiler side of things or the human side of things?
It's the human side I'm primarily worried about.
> All of the rule f
On Thu, Nov 29, 2001 at 01:30:27PM -0500, Eric S. Raymond wrote:
> Tom Rini <[EMAIL PROTECTED]>:
> > I don't know. How is it harder to validate
> > choice kernel_format_PPC
> > VMLINUX ZIMAGE ZNETBOOT
> > default ZIMAGE
> > choice kernel_format_ix86
> > VMLINUX ZIMAGE BZIMAGE BZDISK
Tom Rini <[EMAIL PROTECTED]>:
> I don't know. How is it harder to validate
> choice kernel_format_PPC
> VMLINUX ZIMAGE ZNETBOOT
> default ZIMAGE
> choice kernel_format_ix86
> VMLINUX ZIMAGE BZIMAGE BZDISK
> default BZIMAGE
> Than:
> choice kernel_format
> VMLINUX ZI
On Thu, Nov 29, 2001 at 01:15:03PM -0500, Eric S. Raymond wrote:
> Tom Rini <[EMAIL PROTECTED]>:
> > I'm just pointing out that we'll end up with somelike really long and
> > ugly since there'll be at least 3 'defaults' and probably more. If you
> > think it's better to have lots of the test ? a
Tom Rini <[EMAIL PROTECTED]>:
> I'm just pointing out that we'll end up with somelike really long and
> ugly since there'll be at least 3 'defaults' and probably more. If you
> think it's better to have lots of the test ? a : b's nested instead of
> making these things architecutre-specific, that
On Thu, Nov 29, 2001 at 12:53:42PM -0500, Eric S. Raymond wrote:
> Tom Rini <[EMAIL PROTECTED]>:
> > On Thu, Nov 29, 2001 at 12:16:45PM -0500, Eric S. Raymond wrote:
> >
> > > I think I may have a better idea. Let the default be a ? : name-valued
> > > expression. So your format choice could l
Tom Rini <[EMAIL PROTECTED]>:
> On Thu, Nov 29, 2001 at 12:16:45PM -0500, Eric S. Raymond wrote:
>
> > I think I may have a better idea. Let the default be a ? : name-valued
> > expression. So your format choice could look something like this:
> >
> > choices kernel_format
> > VMLINUX VML
On Thu, Nov 29, 2001 at 12:16:45PM -0500, Eric S. Raymond wrote:
> I think I may have a better idea. Let the default be a ? : name-valued
> expression. So your format choice could look something like this:
>
> choices kernel_format
> VMLINUX VMLINUZ IMAGE ZIMAGE BZIMAGE
> default
Keith Owens <[EMAIL PROTECTED]>:
> >Ugh. That's nasty. Can you imagine a change in the spec language that
> >would make this unnecessary?
>
> The problem is the default which needs to vary from one arch to
> another. i386 defaults to bzImage, ia64 to vmlinuz etc. The default
> choice for one
Giacomo Catenazzi <[EMAIL PROTECTED]>:
> Eric: Could you finally define what is -i and -I ?
> In development of CML2 the definition was changes continuosly,
> and I thinked because of bugs, but now I don't understand.
They have never changed meaning since I originally implemented.
> My orig
Giacomo Catenazzi <[EMAIL PROTECTED]>:
> The main point is: Could we find easily all
> 'orphaned file' with the new kbuild-2.5?
> (outside Documentation, it sould be few README and
> some skeletons, no more 'orphaned' files).
My piece of kbuild-2.5 includes a cross-reference analyzer called kxref
John Cowan <[EMAIL PROTECTED]>:
> > Keith has pointed out a weakness in the language -- there's no way to make
> > the default value of a choices menu dependent on the architecture (an issue
> > for things like kcore format). I am meditating on this.
>
> Suggestion: allow a derived symbol as th
Keith Owens wrote:
>
> This is my list from 2.4.16. A lot are false positives, but some are
> definitely orphaned. If you spot any errors in the Makefile.in rules
> compared to Makefile, let me know.
>
I have check the list (but with 2.4.14, latest version in LXR [lxr.linux.no])
Your rule
Eric S. Raymond wrote:
> Keith has pointed out a weakness in the language -- there's no way to make
> the default value of a choices menu dependent on the architecture (an issue
> for things like kcore format). I am meditating on this.
Suggestion: allow a derived symbol as the default. It mu
On Thu, 29 Nov 2001 12:54:03 +0100,
Giacomo Catenazzi <[EMAIL PROTECTED]> wrote:
>The main point is: Could we find easily all
>'orphaned file' with the new kbuild-2.5?
make -f $KBUILD_SRCTREE_000/Makefile-2.5 allyes $KBUILD_OBJTREE/.tmp_global_makefile
grep '\.[coS] ' $KBUILD_OBJTREE/.tmp_databa
On Thu, 29 Nov 2001 02:46:38 -0500,
"Eric S. Raymond" <[EMAIL PROTECTED]> wrote:
>Keith Owens <[EMAIL PROTECTED]>:
>> I am having some problems with the kernel format option, every arch
>> needs this option but the choice list and default will vary between
>> architectures. I am slowly coming to
Hello.
When updating the new database of autoprobe, I found that
I driver was forgotten in Makefile and Config.in.
From the maintainer:
:
:There should be
:
:if [ "$CONFIG_MIPS_ITE8172" = "y" -o "$CONFIG_MIPS_IVR" = "y" ]; then
:dep_tristate ' IT8172G Sound' CONFIG_SOUND_IT8172 $CONFIG_SO
The latest version is always available at http://www.tuxedo.org/~esr/cml2/
Release 1.9.2: Thu Nov 29 05:43:40 EST 2001
* Rulebase and help sync with 2.4.17-pre1/2.5.1-pre3.
* Rulebase now includes a KERNEL symbol usable in visibilities
so it can track both sides of the
Eric S. Raymond wrote:
> Keith Owens <[EMAIL PROTECTED]>:
>
>>IMHO make oldconfig should always output _exactly_ the same .config as
>>was read in, apart from changes due to new options. CML1 does that and
>>some people rely on this behaviour to detect new options, by comparing
>>the old and new
32 matches
Mail list logo
