Re: 1.8 and mkdir_p

[Bob Proulx]

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/