text: > 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 > > > GNU arch home page: > > >