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
in
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 defined.
[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_tristate
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
done
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 clarity
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, which are you
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
| +- ...
+-TQM
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 them by
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, you
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 Walnut (405GP).
[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
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 bugs. You have
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 NEW
fi
if [ DRV
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.
[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
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 with the
16 matches
Mail list logo
