On Sun, 8 Oct 2000, Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> The patches ad, ae, and af will cause configure to fail on machines
> >> without mktemp. It's not like things get "screwed up" for me, but the
> >> point of Autoconf is portability to *all* machines, so FreeBSD-specific
> >> changes/optimizations(?) seem misplaced.
>
> > Are there any platforms that do not have mktemp? Hard to imagine.
>
> Not hard at all, considering that mktemp(1) is defined by no standard
> according to the references I have handy.
>
> More generally, I have to side with Peter on this: local patches to
> Autoconf are a fine example of Missing The Point. The output script
> has to run everywhere, not only on your own platform.
>
> Also, we not long ago went through the exercise of making sure that all
> committers were standardized on the same version of Autoconf, ie, 2.13.
> Now it emerges that hub.org is running a NON STANDARD version of
> Autoconf: 2.13 + unspecified BSD-originated hacks. So the output is
> likely to change depending on who committed last and where they did it
> from.
Take a look at the patches that I pointed Peter at for these "Unspecified"
patches. The ones that Peter points out merely change from using .$$ to
stipulate the temp file name to using 'mktemp' ...
Now, what I'd be curious about is what platforms this does break things
on, cause if it does, it kinda makes using FreeBSD's autoconf difficult
for non-FreeBSD developments, about as difficult as some of the
Linux-centric ones that we try to port to FreeBSD ...
Basically, what benefits are there to using 'mktemp' over using the shell
based '.$$', and do those developing software under *BSD then break
themselves for other platforms as a result (or force other platforms to
run autoconf to build)?
If using mktemp doesn't break any platform, this is a moot point ... if it
does, then I think it is something that *has* to be fix in the FreeBSD
port itself so that it doesn't make us look FreeBSD-centric in our
development efforts on any other package ...
