Harlan Stenn wrote: > > > I think you are missing my point. > > > The information I am talking about is used for *runtime* decisions - very > > > likely in a script that is in a shared directory used by many different > > > architectures.
If for use at runtime then config.guess is very poorly suited. Do you really want to run the compiler at every run? It is a little slow. On some systems it runs the assembler. > > Oh, well, config.guess isn't designed for that -- it's for compile time > > decisions. In relation to my above comment, clearly for compile time decisions running the compiler makes a lot of sense. > You are clearly joking! I am not saying that I want to run config.guess as > part of every shell RC file. I am saying the information that *should* be > returned by config.guess (in its original spec) are sometimes needed for > runtime decisions in a variety of places. Uh, how does a runtime program obtain the "information that *should* be returned by config.guess" without actually running config.guess? > > uname -s, test -x /bin/rpm, test -x /bin/dpkg > > are probably what you're after. > > Not at all. I have a heterogeneous environment and I use runtime tests such as 'test -f /some/file' often. I also use 'somecommand --someoption' and check the return code often. It works very well. This style of coding is a single source style which works on different operating systems without resorting to trying to enumerate all possible configurations of them. > I am talking about problems that you apparently have never had to really > solve. Hmm... I have a large number (is >2000 machines of different types large?) of machines in my lab. I am willing to guess that I have had to deal with many of the problems which you are about to propose as examples which cannot be solved without using a lookup table. Perhaps I or others can suggest working alternatives to doing a table lookup for your problems as well? But this is clearly getting offtopic for automake. This would be more appropriate for the infrastructures[1] mailing list. Bob [1] http://mailman.terraluna.org/pipermail/infrastructures/
