[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Features command for arch
From: |
Tom Lord |
Subject: |
Re: [Gnu-arch-users] Features command for arch |
Date: |
Wed, 1 Sep 2004 23:08:50 -0700 (PDT) |
> From: [various]
[ A "features" feature is really desirable because several of us
are running into the kinds of problem that such a feature can
solve. ]
Ok, suppose that we accept that.... that still leaves the question of
what *is* the "features" feature?
An answer implies/includes, to name a few things, how feature names
are decided, who/how feature presense/absense is asserted, what valid
feature names are, etc.
James' suggestion was something like named boolean flags, set I
presume in a static array in some C file --- is that about right?
Even if I believe in the need for "features", that approach seems
a little random, to me, on at least a few grounds.
Such a table is easy to code up an understand, but also easy to make a
mistake with while maintaining it (a task akin to double checking
somebody's arithmetic at adding up a long column of numbers).
When I balance my checkbook, I do the math by hand and double check
with a calculator: I'm not sure we can expect people to be so careful
with a centralized "features" table and I'm not sure what the
"features" equivalent of a calculator (for double checking) would be.
Next: I like to be frugal with new design add-ons. If it's *really*
necessary to add something new, hopefully it should solve lots of (or
a very general) existing problems. "Features" seems a bit isolated
to me, in this context.
For example: revision libraries have parameter settings (e.g., the
greedy and sparse flags). Should "features" variables *really* be a
fundamentally different thing? or is there usefully some more general
concept that would make "features" and revision library params the
same thing?
And of course -- the old questions -- are features really just
booleans? who controls the namespace of them and how?
-t
> From: Jason McCarty <address@hidden>
> James Blackwell wrote:
> > Tom Lord wrote:
> > > [....]Asking for `features' in `tla' suggests that we suddenly expect
*lots*
> > > of users to all be running slightly different versions of arch, some
> > > with such and such feature, some without ---- *AND* ----- we expect
> > > that situation to get *so* out of hand that many external tools have
> > > to deal [with] all the possible combinations of features.
> >
> > What? You don't think that's happening? How many are running 1.1.5?
> > 1.2.0? 1.2.1? What about when 1.2.2 comes out?
> > [...]
> > Sure, we can offload the work to the frontends to track it, but that
> > means writing code anyways. The current --version is completely broken
> > for this task. With buildcfg -r, you get one version string. With
> > buildcfg -r, you get a different string (not a version string at all).
> > If you use a tla that comes with a distribution, then it's been screwed
> > with in godawful ways.
>
> I have to agree with James; the syntax of about 20 commands changed
> between 1.1 and 1.2, and testing --version isn't completely reliable. I
> resort to letting the user specify the version, or assume 1.3 when I
> can't tell.
>
> --
> Jason McCarty <address@hidden>
>
>
> _______________________________________________
> Gnu-arch-users mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnu-arch-users
>
> GNU arch home page:
> http://savannah.gnu.org/projects/gnu-arch/
>
>
- Re: [Gnu-arch-users] Features command for arch, tomas, 2004/09/01
- Re: [Gnu-arch-users] Features command for arch, Adrian Irving-Beer, 2004/09/02
- Re: [Gnu-arch-users] Features command for arch, Tom Lord, 2004/09/02
- [Gnu-arch-users] Re: Features command for arch, Stefan Monnier, 2004/09/02
- Re: [Gnu-arch-users] Features command for arch, James Blackwell, 2004/09/02
- Re: [Gnu-arch-users] Features command for arch, tomas, 2004/09/03