Re: 1.8 and mkdir_p

[Harlan Stenn]

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.

While it may be one possible implementation to run a configure script at
startup time, it quickly becomes more difficult (and expensive) to run it
whenever a new process starts.

Also, your goal may be a laudable long-term effort, but we need to evolve to
that place; it won't happen overnight and forcing people (with the current
behavior) to find alternate means to determine this information only slows
progress toward the goal we both seem to have in common.

And  N people writing N different autoconf macros does not do much to
"advance the art".

H
--
> Harlan Stenn wrote:
> > > The differences between ALL of the various linux-gnu implementations are
> > > so slight that they are far more suited to feature tests than something
> > > like this.
> >
> > Are you really serious? ...
> >
> > - RC files?
> > - packaging mechanism?
> > - automount filesystem selection based on different OS versions?
> 
> These are good examples for how autoconf may be useful:
>   - RC files: Check for the existence of /{etc,sbin}/{rc.d,init.d}.
>   - Packaging mechanism: Test for /bin/rpm and {/usr,}/bin/apt
>   - automount filesystem selection: Check for /afs. Check for
>     /etc/init.d/autofs or for autofs in /proc/modules. Check for amd...
> 
> Remember: an autoconf macro is written once. A list of Linux distributions
> that have a particular feature must be maintained forever.
> 
> Bruno
>