Peter Samuelson wrote:
>
> [Greg Banks]
> > Ah, glad you asked, see attached output from the latest version of gcml2
> > (not yet released).
>
> Thank you thank you thank you! Exactly what I wanted!
Pleased to be of service ;-)
> Now, while some (perhaps a lot) of these instances will break w
[Greg Banks]
> Ah. If you're willing to knowingly feed Linus with patches that
> break current config behaviour, then OK we have a way to proceed.
Things knowingly break in 2.5 all the time. I for one have no problem
with this. Especially since the breakage is so easy to pinpoint,
thanks to y
[Sorry, resent to kbuild-devel with attachment gzip'ed]
Kai Germaschewski wrote:
>
> On Mon, 12 Aug 2002, Greg Banks wrote:
>
> > But at this point in the menu tree for 14 of 17 architectures, CONFIG_SCSI has
> > not yet been defined. The result is that CONFIG_BLK_DEV_IDESCSI only works
> > i
Roman Zippel wrote:
>
> I only used it as an example, because my tool has problems to
> automatically convert this construct into something useful (e.g. because
> of CONFIG_WILLOW in 2 seperate choice statements).
You too? I had to rewrite my branch merging code to make CONFIG_WILLOW fit.
Greg
Roman Zippel wrote:
>
> Most should be fixable. The biggest problem are recursive references like
> this:
>
> if [ OLD != y ]; then
> tristate NEW
> fi
> if [ NEW != y ]; then
> tristate OLD
> fi
>
> [...]It's possible to fix this:
>
> tristate DRV
> if [ DRV == y ]; then
> choice OLD NE
Peter Samuelson wrote:
>
> >
> >[...]CONFIG_BLK_DEV_IDESCSI[...]
> >
> That one example is more than enough to convince me *not* to try
> changing the "ignore empty deps" rule for 2.4. 2.5 is a different
> matter, though..
Ah, good.
> This is like the Stanford checker stuff. These are bug
[Roman Zippel]
> with the latest modifications this can be written as:
>
> dep_tristate NEW !OLD
> dep_tristate OLD !NEW
>
> This still has the back reference and you have to run 'make config'
> twice to change NEW from n to y.
I don't see this as a big problem. Most people don't use the bare
On Tue, Aug 13, 2002 at 01:17:15AM +0200, Roman Zippel wrote:
> Hi,
>
> On Mon, 12 Aug 2002, Tom Rini wrote:
>
> > > A bit more flexibility certainly wouldn't hurt. :)
> >
> > What does that gain however? And it wouldn't make as much sense to
> > offer the IBM Spruce (750) next to the IBM Walnu
Hi,
On Mon, 12 Aug 2002, Tom Rini wrote:
> > A bit more flexibility certainly wouldn't hurt. :)
>
> What does that gain however? And it wouldn't make as much sense to
> offer the IBM Spruce (750) next to the IBM Walnut (405GP).
You weren't forced to sort them by cpu type. Maybe it works as is,
On Tue, Aug 13, 2002 at 12:32:50AM +0200, Roman Zippel wrote:
> Hi,
>
> On Mon, 12 Aug 2002, Tom Rini wrote:
>
> > > There is still a bit of overlap. Roughly it's possible to sort the machine
> > > types by cpu type, but IMO it's not the best solution. I think it would be
> > > better to sort th
Hi,
On Mon, 12 Aug 2002, Tom Rini wrote:
> > There is still a bit of overlap. Roughly it's possible to sort the machine
> > types by cpu type, but IMO it's not the best solution. I think it would be
> > better to sort them by general machine type.
>
> Er, 'general machine type' ?
+-RPX
| +- ...
On Tue, Aug 13, 2002 at 12:13:51AM +0200, Roman Zippel wrote:
> Hi,
>
> On Mon, 12 Aug 2002, Tom Rini wrote:
>
> > > More examples of the cml1 limitations can be found in arch/ppc/config.in -
> > > a single choice statement needs to be splitted into multiple choice
> > > statements.
> >
> > Er,
Hi,
On Mon, 12 Aug 2002, Tom Rini wrote:
> > More examples of the cml1 limitations can be found in arch/ppc/config.in -
> > a single choice statement needs to be splitted into multiple choice
> > statements.
>
> Er, which are you referring to here? All of the choice statements are
> done for cl
On Mon, Aug 12, 2002 at 09:45:37PM +0200, Roman Zippel wrote:
> More examples of the cml1 limitations can be found in arch/ppc/config.in -
> a single choice statement needs to be splitted into multiple choice
> statements.
Er, which are you referring to here? All of the choice statements are
do
Hi,
On Mon, 12 Aug 2002, Kai Germaschewski wrote:
> Of course, this is a 2.5 change, though the only potential for breakage
> are the dep_* statements which are arguably already broken. It shouldn't
> be too hard to come up with a script which points out the dep_* statements
> which reference sy
[I wrote]
> > This stuff is trivial enough, and easy enough to test, that I
> > think it could go in 2.4, yes.
[Greg Banks]
> I think you're underestimating the Gordian knot that is the CML1 corpus.
Yes, very possibly.
> To pick an example, in 2.5.29 drivers/ide/Config.in:17 is
>
>dep_t
On Mon, 12 Aug 2002, Greg Banks wrote:
> > > I'm pleased to see that you have preserved those semantics. There
> > > are many places in the corpus where a dep_* lists as a dependency a
> > > variable which is not defined until later, or is only defined in
> > > some architectures, or is never de
Peter Samuelson wrote:
>
> > You're willing to potentially perturb 2.4?
>
> This stuff is trivial enough, and easy enough to test, that I think it
> could go in 2.4, yes.
I think you're underestimating the Gordian knot that is the CML1 corpus.
> Obviously xconfig would need to be dealt with
Andreas Schwab wrote:
>
> |> > + case "$arg" in
> |> > + y|m|n) ;;
> |> > + *) arg=$(eval echo \$$arg) ;;
> |>
> |> Don't you want to check at this point that arg starts with CONFIG_?
> |> Also, how about quoting \$$arg ?
>
> The Right Way to write that is like this,
19 matches
Mail list logo
