On Tue, 2004-01-13 at 18:18, Bob Friesenhahn wrote: > On Tue, 13 Jan 2004, Bob Proulx wrote: > > > > > If the releases are all that similar, why not use: > > > > > > i686-GnuLinux-* > > > > > > as your test, and provide the "popular" distributions in the 3rd field? > > > > > > The "magic" command has a large database of selections on it; using this > > > sort of mechanism should greatly ease the burder on the config.* > > > maintainers. > > > > That sounds like the architecture and philosophy of imake. > > Not exactly. Well, if following Harlan's intention then: yes.
> The philosophy of imake is that the imake configuration > is primarily vendor maintained. IMHO, this is functionally basically the same as Harlan's intention: AFAIU, he wants to use the value returned by config.guess as a key to look up "distribution"-/"vendor"-supplied settings for a system. This is basically the same working principle as imake's and therefore suffers from the same deficiencies and drawbacks. Now he is facing what in AI is known as "symbol grounding problem": "Any definition of any symbol can be further fine-grained and is only valid with certain contexts/views." Less abstract: It's the old "Why not "i386-redhat-linux-glibc2-kernel2.2.22-XFree4.3-...-strawberries'n'cream"? question. This question is not solvable in general. Any chosen definition of a symbol (the tuple) is only applicable from given contexts/views (here: by certain applications; the tuple seems to be well suited to libtool's or gcc's demands). Beyond these contexts/views you'll always find cases where you have to resort to other means. Apparently Harlan's intention is such a case and therefore is doomed to fail in longer terms. Whatever definition has been choosen, you will always be able to find a case where someone wants to extend the tuple. Ralf
